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'.
Related
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!
My Angular (Version 5) app is secured with a JWT Token and AuthGuards. In theory a user is able to manipulate form data with Chromes Developer Tools before the aggregated form values are sent to the server. Are there nowadays new good practices to prevent this on client side and therefore I can assume that the data sent over with https to the server can be trusted ?
This Question addresses the problem: A server side session in combination with validation is recommended there. But in a Restful Architecture there is no session anymore and we can´t prevent all combinations of manipulation attempts by using validations on server side. Therefore I am looking for a convenient client side solution, that makes it uncomfortable for the normal user to manipulate with developer tools. Also I know that there can´t be 100% trustful Client implementation. But complicating the manipulation attempts would be nice trade-off.
Consider creating HttpClient interceptors (see https://angular.io/guide/http), which will be automatically invoked for each HTTP request (including the ones initiated by forms). In those interceptors, you can implement some business logic to ensure that the data was not being manipulated by the user.
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 have implemented authentication, based on jwt tokens in my app. But I have some trouble with logout action. When I press logout, I simply clear my local storage from access_token value.
Let's imagine, that user opened three browser tabs with my app. One of them is unprotected and there is some unsaved user input (tab1). Other tabs (tab2,tab3) have protected resources. When user press logout button on tab3, I want to redirect him on login page (because he is on protected tab). Also I want to redirect him on login page when he makes tab2 active, because it also has unprotected resources. But I do not want to redirect him from tab1 (because it is unprotected), and I do not want to renew it, because user will loose his input. How can I implement this?
TL;DR: In order to achieve this, you'll need to implement WebSockets.
A standard single page application written in angular works over HTTP, which, according to wikipedia:
HTTP functions as a request–response protocol in the client–server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.
Request-response is one of the basic methods of communication between computers. One computer sends a request, the other one sends back a response - it's just so simple (on the surface. The underlying technology handles a lot of stuff, but it's out of the scope in this answer).
But, as with any (simple) technology, it has its constraints. A request contains information about its sender. Upon receiving a request, the server handles it and sends back a response to the entity that issued the request.
Now let's consider your scenario
You have 3 opened tabs with your app and 2 problems here:
Suppose you log out on tab 3. Because you use JWT token authentication (actually any token authentication behaves similarly), the proper log out action consists of just removing the token from your local storage in the SPA project instance on the tab 3. The application state of the project in tab 1 and 2 does not change in this case. Also, logging out doesn't require any request to the server, thus no response is send that would somehow notify of the changed authentication status of the user.
Even if you'll send a request to the server to notify it about the log out action on the tab 3, the server does not know about other 2 opened tabs, because the request holds information only about the entity that issued the request, thus it will just send a response to the third tab.
Entering WebSockets
Note: Before reading on, I want to mention that I don't have practical experience with websockets, so you can take everything I write with a grain of salt.
Again, according to wikipedia (highlights are mine):
The WebSocket protocol makes more interaction between a browser and a website possible, facilitating the real-time data transfer from and to the server. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open. In this way a two-way (bi-directional) ongoing conversation can take place between a browser and the server.
WebSockets provides a full-duplex communication channel, meaning that the server doesn't only provide responses to client's request, but also initiate data transmission. This solves the second problem mentioned above leaving you the task to solve the first problem - notifying the server about the logging out of the user. Once the server knows that the user has logged out, it communicates this fact to all other clients, thus synchronizing the state of your single page application among all tabs.
Angular doesn't provide websockets support out of the box, but there are modules that give you the possibility to use them in your project. Just google it.
Hope this helps you.
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