I developed an application using the MEAN stack, where a user can signup and login. When a user returns to the application after some time, I can recognize it using Express Session, but I want him to confirm its identity by typing the password (or a PIN) before giving access to the application.
So I make an HTTP call to an API (passing the password or pin) that will either return true or false to allow access to that page.
Is it possible that someone intercepts the HTTP call (e.g. via DevTools), intercept the returned value and edit it, effectively bypassing the security check?
Or even intercept the router variable and force a navigation to a specific page (not available otherwise)?
Does Angular have in-built securities to prevent this, or do I have to implement it myself (in this case, what is the best practice)?
Thank you so much!
EDIT: As #bsheps pointed out, implementing AuthGuard solved the second point, about manually modifying routes to access reserved pages.I still have to find an answer about the first point. Even when calling an HTTPS endpoint, can someone debug the code and the network requests to edit the response received from the server?
About HTTP security:
HTTP is written in plaintext and not secure. If someone intercepts your communication (Man in the middle attack), they can read your password/pin in plaintext. Additionally, they could also edit it since it is plaintext. For this reason passwords should be sent via HTTPS.
About angular router security:
It is possible to manipulate the routes in the URL. To combat this, you can setup an authGuard for your application that will verify the login before directing to specific pages.
Here is a straight forward example to get you started:
https://alligator.io/angular/route-guards/
Hope this helps!
Related
I am looking to connect to a secure REST service via Angular and have found the official way to do this is to set the authentication ticket as follows:
$httpProvider.defaults.headers.common['Authorization'] = 'dhfkssksk';
However isn't this insecure as anyone can simply view the JavaScript and find out the auth code?
If you mean that your client app is connecting directly to your backend api (i.e. no 3rd party services), then the short answer is yes.
However, there are a few considerations you need to take into account:
You must only send this ticket to your backend and nothing else. I.e. set an HTTP filter in angular that acts on every client-side request and only sends this Auth header if the URL matches your API url.
You need to use SSL, to protect the token during transmission.
I'm currently working on a mobile app that is built primarily with HTML and css, then run with phonegap. Part of the app requires that the user logs in and sync data with a backend. I want it done in such a way that once the user is logged in on their device they will remain logged in until they manually log out; they should only have to enter their information once. I've found some decent information when working with native code, but not so much that applies to my situation.
Right now, I'm not sure how to properly do this in a way that is secure. My first idea was to handle the login normally, then pass back a secret code that is stored both in local storage on the device, as well as in the database under the user that was authenticated with it. On subsequent requests it would pass this and allow access to the user that had a matching secret code. My question is whether this is secure enough to be practical?
I've also done a bit of research and it appears JWT is similar to what I'm looking for? My two concerns for this approach are:
How do I maintain the persistent login with this method.
What prevents someone from spoofing a connection? From what I know there's a secret string that is passed with each request to verify it. But, since the code in my app would be visible to someone who knew how to access it what is to prevent them from learning what the secret is and spoofing a connection?
I assume my questions with JWT are due to me misunderstanding some fundamentals of how it works. If it satisfies what I'm looking to do I'd much rather use a more standardized process like JWT as opposed to writing my own solution.
Am I on the right track with what I'm thinking above or am I way off base?
Your idea is correct and this is how it's usually done. It is a combination of cookie and session concepts. A 'session' is started on the server once the user logs in. The session is identified by a string (e.g. md5 format) and passed back to the client. The string is saved in a cookie on the client, and since cookie info is sent in each HTTP request, the server can assign that request to the session, thus considering your user as logged in. The signout process later basically consists of removing your cookie, and / or sending a request to the server to remove the session object.
In most HTTP server side frameworks there is an API used for sessions, so you don't have to reinvent the wheel. And yes, it is secure enough, as you don't usually base your security on this layer of transport, but rather on a lower layer by introducing https.
I am trying to handle following case, I am new to web-app world so please pardon my ignorance (if any):
Assumptions/Constraints:
I don't have any control over the web-app code base whatsoever.
Authentication is being handled at http proxy level.
Scenario:
User has authenticated with a web-app using SAML and has been accessing the web-app for quite some time.
His authentication token (or cookie) expires.
He submits a form (HTTP POST).
Server needs to perform the authentication workflow again, which requires a HTTP redirect.
Now, the requirement is to somehow resubmit the original HTTP POST, after completing the authentication workflow, automatically for the user. A couple of options I could think of are:
Use javascript injection to store the POST state in browser's sessionStorage and rePOST things after completing the auth workflow. But I couldn't figure how would this work if the original POST was done using XMLHttpRequest ???
Store POST state on server (or proxy) side and do an internal rePOST and return the result to the browser.
Are there any other options ??? It'd be great if we could avoid saving state on server side. How do people usually handle such scenarios?
TIA,
praddy
Generally the second approach is implemented.
You send the request to the server running the application, it preserves the POST data (actually the again doing the authentication does this), sends you to authenticate, redirects you back and POSTs the data again. This feature may already be present in your authentication infrastructure and just needs to be enabled, but that of course depends what you are running.
This feature is sometimes also referred to 'POST data preservation'.
What is the best way to determine if a request being made to my REST service originated from a web client. I know I can look at the user-agent, but my concern is that is very easy to spoof.
The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.
My site is built entirely in HTML and Javascript, any suggestions?
Or is there a good way in Javascript to store a hidden username / password I can use just for my website, without it being displayed to the public?
Thanks,
Adam
Anything put in the javascript can be found by using a debugger, such as Firebug, so even though it isn't visible to the user, it can be found by a user.
But, if the javascript first calls to a REST service to get an encrypted token, then the token, which has a timestamp encrypted within it, could be the password, so you then pass the username and token to call the rest of the REST services.
Your server could then validate that it had created the token and that it is not expired, and that the username matches what was encrypted in the token.
But, this depends on if you have any control over the REST service.
The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.
This is not a good assumption. For the reasons you already gave (easily spoofed User-Agent), anyone could make a request to your application. You can even disable cross origin policy in firefox and chrome from the client side - so even if you could verify the request came from a browser, it's still possible to get around your security measures:
Disable same origin policy in Chrome
There are a couple of standard ways to implement security for this kind of service (as James mentioned, assuming you have control over the REST service).
Use Basic Authentication - If your application is communicating with the WCF service via HTTPS, basic authentication is probably the easiest method. See this question
If both your website and your WCF service are implemented using .NET, and your ASP.NET web application is using Forms Authentication, you could share the Forms Auth cookie and use that for authentication. See this question
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