By default, when the user submits the login form, and is authenticated, he is redirected to the last URL he wished to access, before he logged out (fetched from the request cache) or to the root URL. Additionally, if a 'spring-security-redirect' parameter is found with the form submission request, we are redirected to the value of that parameter.
I wish to use this feature, but in this thread, Luke Taylor mentioned that it would be a security risk, and we should use an additional form field for that purpose, and then customize our LoginSuccessHandler to retrieve and use that form field as we wish.
I am not able to understand the security risk he mentioned, and the reason we should not use a feature that Spring Security has already provided, instead of using our own custom logic. My reasons for wanting to use the functionality are the same as that of the OP in the above thread.
The Attack behinde is some kind of Cross-Site Request Forgery (CSRF-Attack)
If an Attacker (A) send an modified link to Some Person (B) and B have a short look at this link and see it is your application, he might click this link.
Person B enters his credentials and get looged in.
But now the redirect is executed, WITH THE CREDENTIALS OF THAT PERSON B!
So imagine you have an Application where each User can Spend some money by invoking http://yourApp/spendSomeMoney=100 -- (The first fault in that application would be that this is a GET and not a POST)
Now imagine (A) send (B) this link:
http://yourApp/login.jsp?spring-security-redirect=http://yourApp/spendSomeMoney=100
You see the problem.
In general I would stongly recommend to use some CSRF protection filter, no matter I you use that redirect or not.
Related
I'm trying to better understand the mechanism for how Spring CSRF protection works. Suppose I have a site https://example.com/ where people can vote on candidates. Users can also exchange messages. I also have a user logged in, and another user that sends her a message saying to click on the link https://example.com/vote/candiate/30.
If a user clicks on this link, won't the browser send both the CSRF token and the session ID for the logged in user, thereby bypassing the CSRF protection check?
The reason a link is usually not a problem regarding CSRF is that CSRF is only an issue when the request changes something. A link (a GET request) should not change anything. If it does, like in your example it adds a vote to the candidate I suppose, any link from an external origin (a different website) would also be able to exploit "normal" CSRF by just linking to that url.
The problem in the example is not that CSRF protection is inadequate in Spring, the problem is that voting in this case is a GET request, and GETs are not usually protected against CSRF by design. The solution is to change the vote request to a POST, which would then be protected against CSRF (and which would also be more RESTful btw).
Main idea :
When request is submitted, the server received special cookie and waits for defined value in this cookie. If this value will be differet , the request should fail.
So, if service returns form for moving money between accounts, this form includes parameter, that expected to receive when form is submitted, and if data would be sent without this parameter, request wouldn't be proccessed
The general answer you can find everywhere is to use the Signal authenticationRequired(QNetworkReply*, QAuthenticator*), then fill the login credentials into the given QAuthenticator object.
However, this does not work in my case as that signal is never emitted. Reason: The server does not return an authorization failure but redirects me to a login page instead. So my program will just download that page.
I have found out how to catch this by checking the attribute QNetworkRequest::RedirectionTargetAttribute of the QNetworkReply.
So I can detect the redirection and ask the user for auth info.
But... where do I go from there? How do I set the authentication data? Can I manually set a QAuthenticator to my QNetworkRequest or my QNetworkAccessManager? I didn't find a way to do that anywhere, just via the above-mentioned signal/slot mechanism which does not work because it does not trigger.
Any help would be greatly appreciated!
From documentation,
http://qt-project.org/doc/qt-5/qauthenticator.html
QAuthenticator supports the following authentication methods:
Basic
NTLM version 2
Digest-MD5
Since you are getting redirected to a login page, and you haven't indicated if any of the above authentication methods even works, I will assume that it does not because things like Basic authentication is sent on every request to the server. Login pages generally authenticate the client and use some sort of a cookie for future authentication. To do this,
Detect login page
Pass proper credentials to the server (based on what the form wants)
In the QNetworkReply to the login page, look for cookies (Set-Cookie headers).
Pass the relevant cookies back with your requests.
If it works, you are no longer redirected to login page.
For information on cookies, you can get overview via Wikipedia, but for implementation, you need to look at the RFC 6265,
If this is incorrect, and you can use basic authentication, then that information is passed in the URL itself. Set username and password in your QUrl and if it works, you will not be redirected. http://qt-project.org/doc/qt-5/qurl.html#setPassword
I'm working on AJAX login form. On submit it sends login data to back-end. If there is a problem with login, appropriate response is returned. When login data valid, back-end creates a session for user and sends back a URL where user should be redirected. I want to return URL, because it changes depending on multiple user settings (language, personal/business, etc.).
Am I overlooking any security issues with this approach? Is it possible for attacker to redirect user to malicious website when browser trusts URL returned from AJAX call?
No, that's a pretty standard method for handling login via an asynchronous handler (assuming that you're doing this over HTTPS, if not, all bets are off).
And yes, it is possible for an attacker to redirect a user, if you allow the attacker to set where the redirect goes.
So that means that you should validate any user-inputted (and hence potentially attacker set) URLs that you're going to redirect to make sure they are safe. Basically make sure the URL is on your domain, and make sure that it's a valid URL. You can go deeper (check for XSS style attacks, etc), but you usually shouldn't have to as long as you're practicing good security practices in the rest of the application.
But then again, that's just basic application security Filter-In, Escape-Out. So filter the inputted URL, and you should be fine...
i am using JSONP for cross domain ajax. It works perfecly. My doubt is that, is there any security issues while using jsonp?
EDIT
Just saw that there is already the same question: (Is JSONP safe to use?)
well you need to keep in mind that if you use 'jsonp' any external site could also call this script and get the result of you response.
the security problem occurs when the actions or responses are limited in some kind to a login of the user. e.g. if you return certain informations only if the user is logge
if you have information you only send to the client when the user is logged in or if there are certain actions only allowed when the user is logged in it is . so if a user is logged in and browsing to another page, this page could theoretically do jsonp requests for that user.
A user has 2 ways of getting to this MVC3 website.
Through a log in screen.
Redirect from a different website.
I'm currently just showing a session time out page if the session timed out. However, the business now wants to redirect the user back to where he came from on session timeout.
How would I know where the user came from?
By the time I'm out of session, I don't even know who the user was. Although, that wouldn't make a difference, since the same user could come from either place.
Tricky. You could use a similar technique to what happens when you request a page that requires authentication. In that case, you are redirected to the login action, but the original request is added to the query string with http://localhost/Account/Login?returnUrl={your original request here} so that you are taken to your original requested page once you are authenticated.
In your case, you would have to save to the current session the incoming HTTP_REFERER on the login page, then add that as a '?returnUrl=' for every link to the logout page. Then you'll have to add code to the Logout controller method to handle the redirect.
Note that this technique won't work with deep linking to restricted auth pages (as described in the first paragraph), since that would require two redirects. The referrer would not be valid at that point.