I came to a security concern while doing $http.post requests that are received by the backend of my app. I can see all the data that is being sent using for example firebug in Firefox.
Are third parties able to sniff this data? It would be disastrous if someone sniffed the password when someone registers a new account.
Is there a way to secure my AngularJS front-end so that someone won't be able to steal the data in the POST request?
Any advice will be appreciated :)
No javascript can secure your password. Use SSL.
Or better yet, use services your user are already registered to like Google, Facebook or any openID/oAtuh provider so we don't need to go thought the annoying process of creating a new unique password verify the email :)
One of the ways to secure the data being set to/from the backend over HTTP/HTTPS is to not send them in plaintext. For example, it is possible to send md5 digests of login information in an ajax call – and authentication information like passwords etc. should also never be stored as plaintext in your database on the backend.
You might find this https://code.google.com/p/crypto-js/ interesting.
Related
So there's a few things I'm confused about with connecting a frontend to a backend part of a website, and I can't seem to find anything online about it.
Say you have a backend API, which if you had a endpoint which deletes a user, for if they want their account deleted, then what's stopping an attacker from just pinging the end point with a user ID and then it'll delete the user? I've heard that you can use like a password or something similar to stop fake attacks, but what's stopping somebody from just looking through the source code to find the code that is sent along with the request? Do you just use a user ID that would be hard to guess? But if so, why couldn't they just brute force user ID's?
Should the backend be run on the same domain as the frontend? Should you just have to use https://example.com:3000, or should you have to use the ip of the server and send data to https://000.000.000.00:3000?
Any help would be appreciated. I don't know that much about full stack development since I'm just now starting to learn, however what people say seems to be a really insecure way of doing it.
1 - You can safe your backend with a JWT signed by User/Password to ensure that only signed users are calling to your API BACKEND, in your server you can use a service of DDOS and a Firewall to avoid this kind of attack.
2 - a Backend/Frontend of a website can be anywhere in web separated or not, in a home computer or in a cloud service, you must ensure that your Frontend can reach your backend wherever it is. Ofcourse you can do it in a single webserver, and its better for many reasons, such as process of deploy, performance of the website and safety.
and you can always learn more in documentations.
https://laravel.com/docs/9.x/csrf
There are a csrf token stops unauthorized requests from passing .
a good example in Laravel Documentation
I hope it was useful !
I've been tasked with creating an LDAP authentication on a front-end Javascript application.
I am extremely limited on time and have a very small toolset. The toolset is the front-end javascript application and an available C# application which I can make post and get requests to.
I was thinking I could simply make a call such as https://mybackend.com/authenticate
Where I would post a username and password.
And on the backend this would return whether or not the user was valid in the AD. Which I can then use on the front-end to ensure the user has logged in.
Is this approach extremely unsecure or does it have flaws? I'm thinking that if I am posting to the backend above not much will be exposed.
Any tips would be immensely helpful.
Is this approach extremely unsecure or does it have flaws?
This is not insecure, it's the normal way you would do it. One could add more security by adding a CSRF token, which would be validated on the server for any form submit.
And yes, you should send all the data over HTTPS, this will encrypt the payload.
What you are doing is normal for front-end JavaScript framework like Angular. As long as you use Https, you should be ok.
Only issue is how you will handle the subsequence page requests.
There are two ways to handle it –
Easiest way is to use ASP.Net MVC as login page, and use Cookie Owin Middleware. Since same cookie is sent back to server on API calls, you do not need to do any extra works. You can download my sample code at GitHub - OwinAuthenticationService.
Another way is to use Bearer Token in which you will have to send the same token back to server on every page request.
All method are insecure.
Especially without HTTPS.
But you can put the Authentications in the header of message and use a token generated with a key that only server know.
I am implementing a web application composed by a Javascript front end (single page application if you prefer), and a Rails backend.
The front end app make request through API to the server, I want to know what is the best practice for sending the password on the login or the password reset.
Should I send the clear password, or should I send the hash?
I think that both of two solutions have their drawbacks:
if I hash the password with JS, the user will have the code in his browser and can understand how I secure the password.
If I keep it clear, beh, it is just clear and so it can be intercepted.
As long as you're using HTTPS then their password cannot be intercepted. Well.... it probably won't be intercepted. But the tactics that they would have to use in order to capture that password are somewhat out of your control. The user will have to be sure that they are actually connected to your site.
I suggest reading this answer as well.
He goes over what it would take in order to intercept HTTPS communication. Your responsibility would be to make sure that your site only serves over HTTPS and that you have a completely valid certificate.
I have developed an API for my new service and am in process of developing SDKs (php, ruby and JavaScript) for this API.
Some of the calls to API are open to public, but some require API key and API secret. My question is, how do I make sure that people can hide their key and secret from world while using JavaScript API.
I would Imagine the call something like:
jQuery.ajax({
url:'http://api.domain.com/v1/display/',
data: {offset:0, limit:0, apiKey:'apikeynotlikelogin',apiSecret:'apisecretlikepassword'},
success: function(data){
alert(data);
}
});
But almost everyone these days know that if they open firebug or even simplier ctrl+shift+j in chrome, they can see the code together with all information above. I have considered many options, but it seems to me like there is just no way how to hide apiKey and apiSecret on front-end.
Any suggestions? There must be a way Im sure.
Thanks!
EDIT:
Thanks everyone for answers and trying to solve the issue. Here are some of the answers and why is still not what I need:
Using domain name in the request to make sure its from the correct client.
This is valid suggestion, but still could be quite easily faked
Generating unique key for each call
This seems to be more advanced, but again I found it not usable for my case. I need to authorize the "App" (thats what people register in system in order to get credentials and authorize to API) because users will have different levels of privacy set and according to those clients will be served with result.
So If I cam make client to first call "handshake" to get the session unique key, but then again (either in handshake or next request), client has to send his apiKey and apiSecret in order to authorize to API and get the correct result (according to policies etc.) So at the end, it is exactly the same as without the handshake request, anyone who knows the apiKey and apiSecret could first call handshake and then the authorization.
Hope it makes sense
You can make it harder, but you can't really secure it.
You can have them register the pages from which they are going to make the requests, and check that the request originates from an authorized origin when checking authentication. Not perfect, as this can be faked, but harder for a casual user.
Or they can proxy through a server, but this does not help much since they need to secure access to their proxy.
How do you do a jQuery Ajax call and authenticate the call prior to sending the request?
I have not logged in so have have to authenticate. Security is not an issue anyone can get access just need to authenticate. It just basic http authentication you can take a look at the API http://lighthouseapp.com/api/the-basics
Since you don't specify what kind of authentication you're using, I'm going to make some big assumptions that you have some sort of login page/action that you post the username and password to, using those as the parameter names. If you have other fields -- like hidden fields to prevent cross-site request forgeries, you'd need to include those as well. I'm also going to assume that you know you're not already authenticated. There are ways to detect this, but I'm not going to cover them. I'll further assume that you're posting to the web site's actions, not to some API that requires a separate type of authentication.
The first thing you'd do is generate a POST (I assume) to the login action with a correct username/password combination. How you get these is up to you. This will authenticate you with the web site and supply your browser with the appropriate authentication cookie to send with future requests.
You'll need to detect and handle an authentication failure. If your login action understands that it might be invoked via AJAX (using the HTTP_X_REQUESTED_WITH header is a good bet), then it can return JSON with a status setting otherwise you'll need to scrape the returned HTML to figure it out.
Once you have the authentication cookie, you should be able to make your actual AJAX request without any special handling.
If a user on your website is already authenticated, in most circumstances you don't need to do anything - auth cookie will get sent with your AJAX call. Otherwise, you can try HTTP Basic auth.
If you are trying to get javascript to do the authentication without any user interaction, don't.
Hardcoding your authentication logic into code available to the client could severely compromise the security of the API. If you are going to put the username/password into your javascript, why even use one at all?
If you have access to the API and can rework the authentication, you could try a tokening system for authentication. Just my $.02