Is it okay that a website displays the csrf_token as a URL parameter? I have a feeling that I shouldn't be able to see it, but I am no quite sure. If someone can clear this up a bit, I would be grateful!
No, It's not acceptable.
Passing tokens in URLs isn't normally an acceptable solution. Actually it's
in some cases considered a vulnerability.
What if the Website not running under HTTPS?
What if it's running under HTTPS but HSTS isn't enabled on the server? Then SSL-Stripping techniques would be possible and other MITM attacks.
Even if it's running under HTTPS and HSTS is enabled that won't solve the issue.
The token could be exposed in:
Referer Header
Web Logs
Shared Systems
Browser History
Browser Cache
For more information refer to:
Information exposure through query strings in url
OWASP CSRF Cheatsheet
The typical characteristics of a CSRF Token are as follows:
-Unique per user session
- Large random value
- Generated by a cryptographically secure random number generator
CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referer headers if the protected site links to an external site so it is not recommended.
Related
We all know that it's bad to transmit usernames and passwords over plaintext, since they can be easily viewed by anybody looking at the packets, so we use HTTPS to encrypt this data.
I've noticed that many websites just use HTTPS for the login form and use regular HTTP for all other pages (such as StackOverflow). Couldn't somebody see the cookie (like a session cookie) returned from a login form and inject that into their own web requests? Although it won't expose the username and password, it seems like they could impersonate another user by doing this.
Let's say I'm snooping into my friend's internet connection. After my friend authenticates in HTTPS, the server and my friend begin communicating over HTTP and transmit the cookies in plaintext. What is preventing me from using this cookie?
Nothing is preventing you from using the cookie and stealing his sessions. It's a very poor security practice to send cookies over HTTP. In fact this very weakness was used by the Firesheep Firefox extension that made headlines a few years ago. Since then some sites (notably Facebook and Gmail) have moved to HTTPS only. Other sites should follow suit.
It is not really. If an attacker steals the cookie and then uses it, this is known as Session Hijacking.
StackOverflow are aware of this problem and have been looking at moving towards HTTPS everywhere (site network wide).
To prevent a cookie from ever being sent over an insecure connection, the Secure flag should be set. This will stop the browser from sending it over HTTP connections, even if an attacker tried to make it leak from their own site (very easy to do, an attacker could just include <img src="http://www.example.com/anything.jpg" /> in their own site to cause an unsecure cookie to be sent over HTTP and conduct a MITM attack).
I've read OWASP's HSTS cheat sheet at
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Browser_Support
and also watched the related video:
https://www.youtube.com/watch?v=zEV3HOuM_Vw
but still I can't understand how this helps against man-in-the-middle attacks in case of user typing http ://site.com. OWASP claims it helps.
Let's imagine the following scenario: the middle man gets request from victim: http ://site.com. Then he fires HTTPS request himself to https ://site.com and returns content to the user, stripping the HSTS header. All further user input is visible to the attacker.
In my mind, there's no way to protect against MITM unless we're using HTTPS from the beginning.
Does HSTS header really help against MITM attacks?
HSTS helps only if the user agent has visited the site before and there was no interference from a MITM at the time of the first visit. In order words, you are vulnerable the first time you go to the site, but never again.
Since you are still vulnerable the first time, HSTS is far from perfect. But it's better than nothing, since it does protect from an attacker who targets you AFTER you have already visited the site before.
(Except if the user was careful to use https the first time: in that case they are protected the first time and also protected against forgetting to use https on all subsequent visits.)
Firefox is also working on an HSTS preloaded list: http://blog.mozilla.org/security/2012/11/01/preloading-hsts/
The browsers typically maintain the HSTS information in an implementation-dependent secure store of some form. Of course with Firefox and Chrome the code is browseable. See for example https://code.google.com/p/chromium/source/search?q=stsheader&origq=stsheader&btnG=Search+Trunk
I've been thinking about Same Origin Policy and CSRF, and couldn't answer myself why web browser developers don't use a simpler solution.
Instead of disallowing cross domain scripts, why can't they allow any access to any site, but with an empty cookie jar? (or rather, a cookie jar that contains only the cookies of the current domain)
Same thing about any tag (img, script, etc.)
If any access is with no cookies, what CSRF can be done?
Regarding a cookie jar w/ only the cookies of the current domain: the cookies of the current domain may contain session information for example. This information could then be sent over the wire and result in session hijacking (for example).
Even if the scripts did not have cookie information, there could be other sensitive information on a website, perhaps visible through the DOM. This information could then be uploaded cross domain.
As an side, I don't think the same origin policy actually does anything to stop malicious hackers. As you said img's and scripts can make requests out. I can run a server that returns a 404, but keeps a log of the GET requests (for example: maliciouswebsitehere.com/fake404.html?bankaccountnumber=34398439843983&otherinformation=blah)
Hi I have recently read JSP and came across its technologies, mainly session. Under session, I read URL rewriting one of the method that was been done in order to maintain the session with the client. But since the URL rewriting changes the URL with the session ID and it can be visible to the client.
Is that not a security issue? Lets say for example, if any one note this session ID apart from the particular user, and can make a bad use of it? Or else there are techniques for preventing these?
Correct me if am wrong.
Certainly this is a security concern. If you quickly take note of the jsessionid value, either from a by someone else mistakenly in public copypasted URL or a in public posted screenshot of some HTTP debugging tool (Firebug) which shows the request/response headers, and the website in question maintains users by a login, then you'll be able to login under the same user by just appending the jsessionid cookie to the URL or the request headers. Quickly, because those sessions expire by default after 30 minutes of inactivity. This is called a session fixation attack.
You can disable URL rewriting altogether so that the jsessionid never appears in the URL. But you're still sensitive to session fixation attacks, some hacker might have installed a HTTP traffic sniffer in a public network or by some trojan/virus, or even used XSS to learn about those cookies. To be clear, this security issue is not specific to JSP, a PHP, ASP or whatever website which maintains the login by a cookiebased session, is as good sensitive to this.
To be really safe with regard to logins, let the login and logged-in traffic go over HTTPS instead of HTTP and make the cookie HTTPS (secure) only.
URL rewriting of session cookies is discouraged in most (if not all) security circles. OWASP ASVS explicitly discourages its use as it results in exposure of the session identifiers via an insecure medium.
When URL rewriting of session cookies is enabled, the URL could be transmitted (with the session identifier) to other sites, resulting in disclosure of the session identifier via the HTTP Referrer header. In fact, a simple request by a browser to a resource located on another domain will result in possible hijacking (via a Man-In-The-Middle attack) or fixation of the session; this is as good as a Cross Site Scripting vulnerability in the site.
On a different note, additional protection mechanisms like the HttpOnly and Secure-Cookie flags introduced into various browsers for protecting the session cookie in different ways, can no longer be used when URL rewriting of cookies is performed by a site.
I believe you're referring to cookieless sessions. Although I have seen it referred to as 'url rewriting' in Java circles.
There are some extra session hijacking concerns (and they apply across all web development frameworks that support cookieless sessions--not just JSP). But session hijacking is possible even with cookies.
Here's a pretty good in-depth article on MSDN about cookieless sessions and the risks/benefits. Again, these are all platform agnostic.
http://msdn.microsoft.com/en-us/library/aa479314.aspx (toward the bottom)
This is what I came accross checking the OWASP specifications for URL rewriting and it Exposing session information in the URL is a growing security risk (from place 7 in 2007 to place 2 in 2013 on the OWASP Top 10 List).
Options for managing URL rewriting include :
disabling them at the server level.
disabling them at the application level.
An attractive option is a Servlet filter.
The filter wraps the response object with an alternate version, which changes response.encodeURL(String) and related methods into no-operations.
(The WEB4J tool includes such a filter.)
From ha.ckers.org/xss.html:
IMG Embedded commands - this works
when the webpage where this is
injected (like a web-board) is behind
password protection and that password
protection works with other commands
on the same domain. This can be used
to delete users, add users (if the
user who visits the page is an
administrator), send credentials
elsewhere, etc.... This is one of the
lesser used but more useful XSS
vectors:
<IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode">
or:
Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser
I allow users to post images in the forum. How can this be protected against?
I'm using Java Struts but any generic answers are welcome.
If you follow the rules of the HTTP specification, such a kind of attack will make no harm. The section 9.1.1 Safe Methods says:
[…] GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
So all requests that change data on the server side should only be allowed via POST. And even there you should only allow those requests that your system has authenticated by generating tokens that are only valid for a specific form/action.
This attack is simply an HTTP GET request made to any URL. You cannot reliably block it by prevent certain <img> tags.
Instead, you need to make sure that your website has no targets (URLs that respond to GET requests and change things)
If there aren't any "juicy" URLs that respond to HTTP GETs (not POSTs) and change data, the attacker will have nothing to attack. (<img> tags cannot be used to create HTTP POSTs)
Cross-site scripting is one reason why you should not allow forum users to post images by linking to images outside your site.
Image posting should be provided by allowing users to upload the image file to your site and using internal relative URI.
By injecting an <img> tag someone can bypass referer based XSRF protection for a GET request. The reason why is because the referer for the GET request produced by the <img> has the same referer as the host its self. So this would bypass code checking to see if the referer and the host where different.
You shouldn't allow people to put html on your page. In this case you should let users upload them and then host images locally. If you really want people to put IMG tags on your site, make sure the URL isn't pointing to your server, because this what an attack would do! Also don't use referer based XSRF protection, use token based. <img> tag injection cannot bypass token based xsrf protection.
No one seemed to mention that the threat in allowing people to post images is not to you, it's to other sites.
If you allow people to post images but your site has no XSRF vulnerabilities, your site is not in danger; other sites with XSRF vulnerabilities are, as your users will unknowingly make requests to the other site via the embedded image when they visit your site. The malicious <img> tag will look something like this:
<img src="http://my-bank-website.com/withdraw_money.php?amount=100000&account=mandy-the-hacker" />
Note that this is not a real image, but the browser will not know that, so it will make the request anyways, transferring $100,000 to mandy-the-hacker's account, assuming the user is currently logged on to my-bank-website.com. This is how XSRF vulnerabilities work.
The only way to prevent this is to force users to upload images, rather than providing URLs for them. However, the malicious user could still just provide a link to the XSRF vulnerability, so removing the ability to provide URLs doesn't really help anything; you are not really harming the other site by allowing <img> tags, they are harming themselves by not using user-specific tokens in forms.