The related domain cookie attack (more info) allows machines in the same DNS domain to add additional cookies that will also be sent to other computers in the same domain.
This can cause issues with authentication, or at worst be a component in a confused deputy attack.
Question
How can I protect ASP.NET or ASP.NET MVC from this type of attack?
One possible attack scenario
I log into a "secure" web app
I get the credentials for my account
I trick the user into visiting my site on the same DNS domain
I insert the cookie (of my creds)
the user goes back to your app.
Both cookies (or an overwritten one) is sent to the server
User is doing things under my account
That is a simplified example, but the idea can be ported other style of attacks, Im just picking the scenario that doesn't seem "too bad".
One idea how it can "get bad" is if this was step 1 of a two-step attack. Suppose the user uploaded a bad file that was accessible only in his account; the other user then unwittingly downloads that file, running any executable code that is there.
There are a ton of other scenarios that are possible... rather than list them all here I'm trying to figure out how I can protect my server from this type of attack.
Channel Bound Cookies
The following Proposed RFC comes from a Google employee and describes a way for Clients use a self-signed Browser Certificate (thus requiring no confusing "pop-up" for the end user) which can also address the cookie security issue known as "Related Domain Cookies"
What follows below is an extract of http://www.browserauth.net/ , a section of the RFC, some interesting commentary, and some criticism on this extension.
Overview of Channel Bound Cookies
Once the underlying TLS channel uses TLS client authentication (with the TLS-OBC extension), the server can bind its cookies to the TLS channel by associating them with the client's public key, and ensuring that the cookies are only ever used over TLS channels authenticated with that public (client) key.
This means that if such a channel-bound cookie is ever stolen off a client's machine, that cookie won't be able to authenticate an HTTP session to the server from other machines. This includes man-in-the-middle attackers that inject themselves into the connection between client and server, perhaps by tricking users into clicking through certificate-mismatch warnings: such a man-in-the-middle will have to generate its own TLS session with the server, which won't match the channel that the cookie is bound it.
Channel Binding
It's up to the server to decide whether to bind cookies to TLS channels. If the client doesn't support TLS-OBC, or if the cookie it's about to set will be used across different origins, then the server will not channel-bind the cookie. If it does decide to channel-bind the cookie, it should associate the cookie with the client's public key. This is similar to RFC 5929, but instead of the client binding data to the server's public key, in this case the server would be binding data (the cookie) to the client's public key. The server can do this either by simply storing, in a backend database, the fact that a certain HTTP session is expected to be authenticated with a certain client public key, or it can use suitable cryptography to encode in the cookie itself which TLS client public key that cookie is bound to.
In the figure above, the server includes the client's public key into a cryptographically signed datastructure that also includes the authenticated user's id. When the server receives the cookie back from the client, it can verify that it indeed issued the cookie (by checking the signature on the cookie), and verify that the cookie was sent over the correct channel (by matching the TLS client key with the key mentioned in the cookie).
To be continued here.... http://www.browserauth.net/channel-bound-cookies
RFC Snip
TLS Origin-Bound Certificates RFC Draft
(Excerpt)
4.3. Cookie Hardening
One way TLS-OBC can be used to strengthen cookie-based
authentication is by "binding" cookies to an origin-bound
certificate. The server, when issuing a cookie for an HTTP
session, would associate the client's origin-bound certificate with
the session (either by encoding information about the certificate
unforgeably in the cookie, or by associating the certificate with
the cookie's session through some other means). That way, if and
when a cookie gets stolen from a client, it cannot be used over a
TLS connection initiated by a different client - the cookie thief
would also have to steal the private key associated with the
client's origin-bound certificate, a task considerably harder
especially when we assume the existence of a Trusted Platform
Module or other Secure Element that can store the
origin-bound-certificate's private key.
Additional Commentary from public-web-security#w3.org
Also, note that somewhat counter-intuitively, channel-bound cookies protect against many related-domain attacks even if the client cert that they are bound to has broader scope than a web origin.
Imagine, for a moment, that a user-agent creates a single self-signed certificate that it uses as a TLS client cert for all connections to all servers (not a good idea in terms of privacy, but follow me along for this thought experiment). The servers then set cookies on their respective top-level domains, but channel-bind them to the user-agent's one-and-only client cert.
So, let's say that an app app.heroku.com sets a (channel-bound) cookie on my browser for domain .heroku.com, and that there is an attacker on attacker.heroku.com. One attack we might be concerned about is that the attacker simply harvests the .heroku.com cookie from my browser by luring me to attacker.heroku.com. They won't be able to actually use the cookie, however, because the cookie is channel-bound to my browser's client cert, not to the attacker's client cert.
Another attack we might be concerned about is that attacker.heroku.com sets an .heroku.com cookie on my user agent in order to make me log into app.heroku.com as himself. Again, assuming that the only way the attacker can obtain the cookies is by getting them from app.heroku.com, this means that the cookies he has at his disposal will be channel-bound to his client cert, not to my client cert - thus when my browser sends them to app.heroku.com they won't be valid.
The TLS-OBC proposal, of course, assumes more fine-grained "scopes" for the client certificates. The reason for that, however, is purely to prevent tracking across unrelated domains. Related-domain attacks are already mitigated even if we used coarse-grained client certificates and coarse-grained (i.e., domain) cookies. I, at least, found this a little counter-intuitive at first, since the other proposed defense it to forbid coarse-grained cookies altogether and use origin cookies instead.
Criticism from public-web-security#w3.org
There are a number of issues that need to be considered for TLS-OBC; I'll highlight a couple here that I'm aware of.
Some SSL handshake logic may need to be modified slightly; see https://bugzilla.mozilla.org/show_bug.cgi?id=681839 for technical discussion.
There are potential privacy considerations; in particular if the unique client certificate is sent in cleartext before the negotiation of the master secret, a passive network observer may be able to uniquely identify a client machine. The attacker would already have the client's IP address, so this isn't a huge problem if the certificate is regenerated on an IP address change, but that would nullify much of the authentication benefit. A proposal to allow a client certificate to be sent after the master secret negotiation has been made. (can't find the bug right now, sorry)
One proposal how #2 could be addressed is here: https://datatracker.ietf.org/doc/html/draft-agl-tls-encryptedclientcerts
There are tricky interactions with SPDY. There will be updates on browserauth.net for this.
Fix the RFCs
The core issue here seems to be that any host can write a cookie that can be overwritten by any other host in the same domain. What if there is a way to write a value to the client that absolutely can not be overwritten by any other host? I haven't found anything like that is also automatically included in the HTTP header (like a cookie)
Here are three solutions that might work, though I like Solution 2 or #3 if browsers implement it correctly
Solution 1: Add more information when uploading cookies to the server
When the client sends cookies to the server, also include the domain of the cookie that was sent. The server then knows what domain and path to look for. This means the client adds a new HTTP header Cookie-Details on every request:
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Cookie-Details: name="value":"domain":"path":"IsSecure":"IsHTTPOnly"; name2="value2":"domain2":"path2":"IsSecure":"IsHTTPOnly"
Accept: */*
The server can then ignore the details field, or prefer it over the one that doesn't provide the details. The reason I included the "value" field in the details section is because the server would not be able to tell the difference between two cookies that have the domain set to example.com and secure.example.com if they both cookies have the same name. Most browsers will send the values in a random order.
Perhaps this can be optimized so that the server can tell the client if this new cookie format is supported or not, and the client can respond accordingly.
Solution 2: Extend HTML5 LocalStorage so that data is (optionally) automatically inserted into the HTTP header
If we could extend HTML5's LocalStorage to allow a Secure/HTTPOnly data, we can imitate what is done in Solution #1 above, but have the change driven by the HTML5 LocalStorage W3C Working Group
The benefit of this is that there is less overhead than solution #1, since the more verbose cookie details are only sent to the server when its needed. In other words if a sensitive value is saved using the "new cookie details" format into LocalStorage, then there is a clear separation of what data needs to be sent, and in what format.
Solution 3 "Cookie validation"
A user visits a web app that has this "special" validation mode enabled.
On the HTTP response some cookies are sent to the browser. The cookies can be HTTP Only, Secure, ...anything)
A alongside the cookies, another header is sent to the cookies: Set-CookieValidationHash. It contains A JSON array of SHA-256 hashed cookie keys and values, and specifies the expiration of the value
The browser then logically ties this header to the cookies with the following behavior
This header is placed into a "Cookie Validation Jar" that can only be written to by the same DNS Domain, and DNS Scope
This header is opaque to the client and is returned to the server on every HTTP request (like a cookie)
The server will use this field to validate the cookies that are sent, and issue an error (or whatever) if the checksum fails.
Sourced from: http://www.w2spconf.com/2011/papers/session-integrity.pdf
5.2. Integrity through Custom Headers
Instead of securing cookies, we can achieve session integrity
by choosing a new method of storing and transmitting session
state. While this could be done using special browser plugins
like Flash, we would rather choose a design with the fewest
dependencies, so we will focus only on basic HTTP tools.
The basic form of an HTTP request has very few places that
are suitable for sending data with integrity. Data in the URL
or entity body of HTTP requests has no integrity, because
those parts of the HTTP request are writable across origins
and thus spoofable by an attacker. Cookies are also weak in
this regard, as they can be overwritten by the attacker in our
threat model. However, through the use of a JavaScript API
called XMLHttpRequest (XHR), we can send data in a custom
header.
Background. XMLHttpRequest (XHR) allows HTTP
requests containing custom headers to be made, and the
responses read, but only to the origin of the executing
JavaScript.(See Note5) As a result, requests made via XHR can be
distinguished by a server as necessarily originating from the
site itself.
Design. We will not use cookies at all, and instead pass
a session identifying token in a custom HTTP header which is
only written via XMLHttpRequest. The server should treat all
requests lacking this custom header, or containing an invalid
token, as belonging to a new, anonymous session. In order to
persist this session identifying token across browser restarts
and between different pages of the same application, the token
can be stored in HTML5 localStorage by JavaScript upon
successful authentication.
Security. Observe that in this model, the session identifying token will only be sent to the origin server, and will
not be included in the URL or entity body. These properties
provide confidentiality and integrity, respectively. Unlike with
cookies, the token cannot be overwritten by the attacker, since
localStorage completely partitions data between origins in
most browsers (See Note 6). A site using HTTPS can ensure that the token
is only sent over HTTPS, thus ensuring the secrecy of the
token even in the presence of an active network attacker. In
addition, because this token is not sent automatically by the
browser, it also serves to protect against CSRF attacks.
Disadvantages. This approach, however, has several disadvantages. First, it requires all requests requiring access to
a user’s session to be made using XMLHttpRequest. Merely
adding a session identifying token explicitly to all requests,
much less doing them over XHR, would require major changes
to most existing websites, and would be cumbersome and
difficult to implement correctly without a framework. This
is even further complicated if requests for sub-resources like
images require access to session state, since it is not trivial
to load images via XHR. Third, since this design depends on
the presence and security of HTML5 localStorage, it will be
impossible to implement on some legacy browsers
(Note 5) Sites may make cross-site requests using XHR if supported by the
browser and authorized by the target server
(Note 6) True in Chrome, Firefox, Safari, and Opera on OS X, several Linux
distributions, and Windows 7. Internet Explorer 8 does not partition HTTP
and HTTPS, but Internet Explorer 9 does.
Main Points
Not give permission for run in the upload directories (an attacker can be from inside).
Get all possible user information's that is connect to the server (cookie is only one).
Monitor the server and alerts (found/see him, stop him, close the door).
Answer to
Suppose the user uploaded a bad file that was accessible only in his
account; the other user then unwittingly downloads that file, running
any executable code that is there.
First of all you must not allow to run anything on your uploaded directories, because even your regular users can upload an aspx page and run it and browse your files. The first step for this is to add on your upload directories this web.config (but also set the permissions to not allow to run anything).
<configuration>
<system.web>
<authorization>
<deny users="*" />
</authorization>
</system.web>
</configuration>
relative : I've been hacked. Evil aspx file uploaded called AspxSpy. They're still trying. Help me trap them‼
Stealing the cookies
Lets see how we can identify the user.
Cookie
Browser ID
Ip including proxy and forward ips.
Browser have javascript enable (or not).
Direct ask for password.
Other file stored on client.
Now, for every logged in session, we can connect the first four information's together, and if any of them change we can log him out and ask again to sign in.
Also is critical to connect some how (with a line on the database) the cookie with the logged in status of the user, so if the user log out, no matter if some steal his cookie, not to be able to see the pages - what I mean is the cookie that let him log in must not the only one that we rely on, but also our data to track the status of the user.
In this case even if some steal the cookie, if the user log out after some actions, the cookie is not useful any more.
So what we do is that we connect the cookie+ip+browser id+javascript information's per login, and if any of them change, we not trust him any more, until log in again.
Cookies
One cookie is not enough. We need at least two cookies, one that work only on secure pages, and is required to be https secure and one that work on all pages. This two cookies must be connected together and this connection must also be hold on server.
So if one of this cookie not exist, or the connection is not match, then user again not have permission and need to log in again (with alert to us)
relative: Can some hacker steal the cookie from a user and login with that name on a web site?
An idea to connect cookies together. With this idea I connect the session cookie with the authentication cookie.
If all fails
There are some steps (or actions) that a hacker follow (do) when get to a site so be able to gain from this window opportunity and left a back door open.
Create a new administrator account.
Upload a file to run as browser and executable.
As I say we never allow to be able to upload a file that can be run, so this is easy.
The other to create a new administrator account is the one that we need to add an extra password that is not saved to any cookie, or nether exist anyway on client.
So for rare actions like, New User from backoffice, change the privilege of the users, delete a user, etc, we need to request a second password every time that only the administrator knows.
So second password is the final messure.
One final idea
One idea that I have not made, is to store some how information's on the client other than the cookie, the can not be stolen like the cookies, or even if he can be stolen is hidden somewhere on all the data that is impossible to find it.
This infomation's can be an extra id of the user together with the cookie, browser data, IP.
I am thing some possible places but not have tested or try them yet in real life. So this is some placed.
Custom extension, or plugin, unfortunately different for every browser that have the ability to save data and then we can use them to communicate with the server. This is required action from the user, to install this plugin - and for regular users this can make him afraid and go.
Hidden code inside a good cached image, on the header of it, eg on etag. This also is easy to not work because we can not be sure that the image request to reload...
Some other browser abilities, eg to read and use a client certificate, that can be used to exchange encrypted data with the server. This request action from the user to install this certificate, and from our part to create them different for every user. Good for bank accounts but not for simple users.
So this is my ideas... any critic, or a solution (for how to store small information's on client other than the cookie) is welcome.
Implementation
To make it real secure we need to keep track of the user on the server, and on database. A table that connect the user, with the ip, with the browser id, and other status, like if now is log in or not, is a measure that we can use to take decisions.
If not be able to use a database, or not like to make it difficult, then the connection can be bu hashing some data together and check if this hash is the same.
For example we can set a cookie with the hash of (Ip+BrowserID) and check if this much or not.
Alerts - Log
All the above they try to be automate. How ever I suggest also to show to the user and to the administrator some information's to diagnose and prevent an attack. This information's can be.
To the user
Last 10 sign in information's (IP, DateTime, Success or not)
Send email on user about some actions (for high security sites), like log in, log out, critical actions.
To the administrator.
Log and show any fail of the connection on the four parametres Cookie+IP+BroserID+Javascript Enable). The more the fail in short time, the more attention required.
Check for fail login.
Check for page read from user with out cookie enable (or save) and javascript is disabled, because this is how scanner identified from my experience.
Source: Origin Cookies Proposal from Web 2.0 Security and Privacy Conference
.
6. Session Integrity in Future Browsers Neither of the previous solutions, nor others considered using existing browser technologies,
provide sufficient security while remaining deployable for existing
sites. Therefore, we propose an extension to cookies called origin
cookies. Origin cookies allow existing web applications to secure
themselves against the described attacks, with very little complexity
of implementation on the part of either the web application or the
browser, with transparent backwards compatibility for browsers that do
not yet implement origin cookies, including legacy browsers that may
never support them, and imposing no burden on existing web sites that
have not enabled origin cookies. This is not a trivial problem to
solve, as evidenced by existing proposals that fail to meet one or
more of the above desired properties. For example, sending the origin
of every cookie on each request is one common idea. This is much more
complicated than necessary, and imposes a much larger burden on web
sites, including ones that don’t even know how to effectively use this
information.
6.1. Origin Cookies The real problem with using cookies for session management is lack of integrity, specifically due to the
ability of other origins to clear and overwrite cookies. While we
cannot disable this functionality from cookies without breaking many
existing sites, we can introduce new cookie-like functionality that
does not allow such cross-site modification.
Design. Origin cookies are cookies that are only sent and only modifiable by requests to and responses from an exact origin. They are
set in HTTP responses in the same way as existing cookies (using the
Set-Cookie header), but with a new attribute named ‘Origin’. In order
to enable web applications to distinguish origin cookies from normal
cookies, origin cookies will be sent in an HTTP request in a new
header ‘OriginCookie’, while normal cookies will continue to be sent
in the existing header ‘Cookie’.
HTTP/1.1 200 OK
...
Set-Cookie: foo=bar; Origin
...
Fig. 2. An HTTP response setting an origin cookie.
GET / HTTP/1.1
Host: www.example.com
...
Origin-Cookie: foo=bar
...
Fig. 3. An HTTP request to a URI for which an origin
cookie has been set.
For example, if in response to a GET request for
http://www.example.com/, a response as in Figure 2 is received, then
an origin cookie would be set with the key ‘foo’ and the value ‘bar’
for the origin http://www.example.com, and would be sent on subsequent
requests to that origin. A subsequent GET request for
http://www.example.com/ would look like Figure 3. Requests made to any
other origin, even https://www.example.com and http://example.com
would be made exactly as if the origin cookie for
http://www.example.com was never set. The Origin attribute extending
the semantics of Set-Cookie itself is subtle and implies several
semantic changes to other settable attributes of cookies. If the
Origin attribute is set, the Domain attribute is no longer
appropriate, and therefore should be ignored. Similarly, the Secure
attribute is no longer appropriate, since it is implied by the scheme
of the origin for the cookie: if the scheme is https, the the origin
cookie effectively has the attribute – since it will only be sent over
a secure channel – and if the scheme is anything else, the cookie does
not have the attribute. Because the same-origin policy considers
different paths to be part of the same origin, the Path attribute of
cookies provides no security and should also be ignored. The semantics
of other attributes, such as HttpOnly, Max-Age, Expires, etc. remain
unchanged for origin cookies. Normal cookies are uniquely identified by
their key, the value of the Domain attribute, and the value of the
Path attribute: this means that setting a cookie with a key, Domain,
and Path that is already set does not add a new cookie, but instead
replaces that existing cookie. Origin cookies should occupy a separate
namespace, and be uniquely identified by their key and the full origin
that set it. This prevents sites from accidentally or maliciously
deleting origin cookies, in addition to the other protections against
reading and modifying, and makes server-side use of origin cookies
significantly easier.
Security. Because origin cookies are isolated between origins, the additional powers of the related-domain attacker and active network
attacker in overwriting cookies are no longer effective, since they
were specifically exploiting the lack of origin isolation with existing
cookies, whether the ‘confusion’ was due to the scheme or domain of
the origin. Absent these additional powers, the related-domain
attacker and active network attacker are equivalent to the web
attacker, who cannot break the security of existing session management
based on the combination of cookies and secret tokens.
Implementation. Integrating origin cookies into existing browsers will not involve significant modifications. As a proof of concept, we
implemented origin cookies in Chrome. The patch totals only 573 lines
Source: W3C Mailing Lists
IETF TLS working group has a proposal to bind cookies to TLS client certificates, so as long as the private key corresponding to the cert is only on one machine, the cookie can only be used on one machine.
If you want to emulate the TLS client cert approach, you could use localStorage to store a private key, and use JS crypto 1 to replace document.cookie with a signed version. It's a little clunky, but it might be made to work. (Obviously, would be better with web crypto 2)
1 for example: http://www.ohdave.com/rsa/
2 http://www.w3.org/community/webcryptoapi/
From http://www.codeproject.com/Articles/16645/ASP-NET-machineKey-Generator
Whenever you make use of ViewState, Session, Forms authentication, or other encrypted and/or secured values, ASP.NET uses a set of keys to do the encryption and decryption. Normally, these keys are hidden and automatically generated by ASP.NET every time your application recycles
If the two websites are different web applications, by default they will have different keys so one will not be able to read encrypted tokens generated by the other. The exception to this is if they are using common values in a global web.config or machine.config.
From machineKey Element, decryptionKey: http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx
AutoGenerate, IsolateApps Specifies that the key is automatically generated. This is the default value. The AutoGenerate modifier specifies that ASP.NET generates a random key and stores it in the Local Security Authority (LSA). The IsolateApps modifier specifies that ASP.NET generates a unique encrypted key for each application using the application ID of each application.
So unless the machineKey element is being used to set the decryptionKey at a global level, the method you described should not work. If it is set, you could override at application level using the web.config file.
You could set a unique machineKey in the web.config for your application. This way only authentication cookies emitted by that application can be decrypted. If the user visits a malicious site on the same domain, this other site might indeed add an cookie authentication cookie with the same name but different value, but it won't be able to encrypt and sign it with the same machine key used by your application and when the user navigates back an exception will be thrown.
The answer is simple: Always bind sessions to a specific client IP (this should be done in any modern web application anyway) and do not use cookies for any other purpose.
Explanation: you always send a single SESSIONID cookie back to the client, which holds no information - its just a very long random string. You store the SESSIONID along with the authenticated user IP within your webapps scope - like i.e. the database. Although the related cookie attack can be used to swap SESSIONID cookies around between different clients, no client can ever masquerade as another user or perform any actions, as the SESSIONID is only considered valid and the privileges are only granted, if its send from the associated IP address.
As long as you do not store actual data which is considered private into the cookie itself, but into the session state on the server side (which is selected solely by the SESSIONID cookie) the related cookie problem should be no problem for you.
I'm writing a mostly ajax-driven web application and I'm looking at how to protect the user from CSRF attacks. I'm planning to run the pages of the application where the user is logged in to do his work in HTTPS mode.
Does running the page on HTTPS work to protect against CSRF attacks?
No, running a page on HTTPS does not protect it from CSRF. The fact that the communications between the browser and server is encrypted has no bearing on CSRF.
I suggest reading the OWASP guidance on preventing CSRF.
A general, golden rule woule be:
Never trust that the incoming client request is a legitimate one. Be always suspicious and assume that the request could be maliciously forged.
Few specific rules beyond the mentioned OWASP article:
if your data needs authentication/authorization, avoid generic interfaces on the server, like the CRUD interface. easy to code, difficult to authorize specific requests coming from clients. instead, offer a SOA-style interface with explicit methods dedicated to specific use cases where you will have direct control over requests and their parameters.
http://msdn.microsoft.com/en-us/library/ms954638.aspx
even if the framework provides some control over the request validity (ASP.NET viewstate), check again if the user is authorized to pass the set of incoming parameters.
I'll try to explain:
• HTTPS prevents from someone on the same network to get your Session KEY/ID. Say they got your session identification key/id, then they can fake your IP if needed and send all POST requests they want back to server.
With HTTPS all HTTP body (the whole "HTML") is encrypted. Hence no session key is being guessed.
• What happens in CSRF is that the user is clicks a link, which also creates a request to another server and communicates with it, say using user's session but NOT ON THE SAME NETWORK. Means that it cannot listen to what the server replies back to user. If the attacker knows the replies and can communicate them, voila. No problem. No money's left on the user account. But if the server sends a random token to the IP associated with the session, then the attacker cannot guess it on a different network!
The best possible solution is to include secret tokens - to identify the user - in form submissions to the server. Refer to the following links for more information.
http://en.wikipedia.org/wiki/Cross-site_request_forgery
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
http://seclab.stanford.edu/websec/csrf/
https doesn't safeguard your app from xss attacks. You need csrf token which should be (1) encrypted (2) expiring after some time (3) CSRF token based on page & time
I have been investigating this for some time, but I haven't found anything to satisfy my curiosity. Is it possible, as a user, to be the victim of a CSRF attack if cookies are disabled. Obviously CSRF depends on the users browser to send the user's credentials with the forged request to the legitimate server. Besides IP addresses, browsers don't automatically send in any other session values do they? In that case, as long as a user can login with cookies disabled, they would be safe from CSRF even on vulnerable websites.
So, you have to ask yourself how does the server know one client from another? In majority of cases, it is the session cookie, but there are other ways as well.
Consider an admin application, that is configured to work only if accessed from localhost. Here, the server is trusting the IP Address of the browser. Now, if an attacker creates a page like <img src="http://localhost/do/something/harmful"/>, and somehow gets the administrator to visit his page, you have a CSRF.
Other examples include abusing Http basic and digest authentication, as Bruno already pointed out.
There are other forms of authentication supported by browsers, in particular HTTP Basic and HTTP Digest, as well as SSL/TLS client-certificates. Unfortunately, the interface to "log out" when using these mechanisms is usually fairly poor. Unlike cookies and forms, stopping to use the credentials is controlled by the browser (not by the server and its cookies), but the buttons are at best in some advanced menu in general (if they exist at all).
Reading this question,
Different users get the same cookie - value in .ASPXANONYMOUS
and search for a solution, I start thinking, if it is possible for some one to really steal the cookie with some way, and then place it on his browser and login lets say as administrator.
Do you know how form authentication can ensure that even if the cookie is stolen, the hacker does not get to use it in an actual login?
Is there any other alternative automatic defense mechanism?
Is it possible to steal a cookie and
authenticate as an administrator?
Yes it is possible, if the Forms Auth cookie is not encrypted, someone could hack their cookie to give them elevated privileges or if SSL is not require, copy someone another person's cookie. However, there are steps you can take to mitigate these risks:
On the system.web/authentication/forms element:
requireSSL=true. This requires that the cookie only be transmitted over SSL
slidingExpiration=false. When true, an expired ticket can be reactivated.
cookieless=false. Do not use cookieless sessions in an environment where are you trying to enforce security.
enableCrossAppRedirects=false. When false, processing of cookies across apps is not allowed.
protection=all. Encrypts and hashes the Forms Auth cookie using the machine key specified in the machine.config or web.config. This feature would stop someone from hacking their own cookie as this setting tells the system to generate a signature of the cookie and on each authentication request, compare the signature with the passed cookie.
If you so wanted, you could add a small bit of protection by putting some sort of authentication information in Session such as a hash of the user's username (Never the username in plain text nor their password). This would require the attacker to steal both the Session cookie and the Forms Auth cookie.
The scenario where a cookie can be stolen happens in a public wireless environment. While you or I would never operate in such a setup, it may be impossible to prevent your customers from doing so.
If the attacker knows what secure site you're connected to, the idea is that your browser can be tricked into posting to a non-secure version of the same url. At that point your cookie is compromised.
That's why in addition to httpOnlyCookies you'll want to specify requireSSL="true"
<httpCookies httpOnlyCookies="true" requireSSL="true" />
I disagree with The Rook's comment, in that I find it unfair;
#Aristos i updated my answer. But to be honest, if your using a Microsoft development platform your application will be inherently insecure. – The Rook 22 mins ago
Security doesn't happen by accident and it doesn't happen "right out of the box", at least not in my experience. Nothing is secure until it's designed to be so, regardless of the platform or the tools.
There are many ways that a session id can be leaked to an attacker. XSS is the most commonly used attack to hijack a Session ID and you should test for XSS vulnerabilities in your application. . A common method of improving the strength of a session is to check the IP address. When the user logs in, record the ip address. Check the IP address for every request, if the IP changes then its probably a hijacked session. This secuirty measure could prevent legitimate requests, but that is very unlikely.
Do not check the X-Forwarded-For or User-Agent, its trivial for an attacker to modify these values.
I also recommend enabling httpOnlyCookies in your web.config file:
<httpCookies httpOnlyCookies="true"/>
This makes it more difficult for an attacker to hijack a session with javascript, but its still possible.
I don't know the specifics of the cookie in question but it's generally bad practice to store both the username and password in a user cookie. You generally want to only store the username in the cookie along with other non sensitive information. That way the user is prompted to provide their password only when logging in.
I am working on this, and I am coming up with an idea, that I am not sure if it is 100% safe, but is an idea.
My idea is that every user must pass from the login page.
If some one stole the cookie, is not pass the login page, but is go direct inside to the rest pages. He can not pass the login page, because did not know the really password, so if he pass he fail anyway.
So I place an extra session value, that the user have been pass with success the login page.
Now inside every critical page, I check that extra session value and if found it null, I login off and ask again for the password.
Now I do not know, maybe all that done all ready by microsoft, need to check it more.
To check this idea I use this function that direct make a user logged in.
FormsAuthentication.SetAuthCookie("UserName", false);
My second security that I have all ready fix and use, is that I check for different ips and or different cookie from the same logged in user. I have made many think on that, many checks (if is behind proxy, if is from different countries, what is look for, how many times I have see him, etc...) but this is the general idea.
This video show exactly what I try to prevent. By using the trick I have describe here, you can not just set the login cookie only.
Just sharing my ideas...
I'm currently researching cross-domain SSO implementations, and I may not be able to use a third party SSO provider.
I found a custom implementation online that involves a series redirects and an encrypted querystring parameter.
MrUser logs into http://www.foo.com
MrUser clicks a link to http://www.bar.com/page.aspx
MrUser is not authenticated on bar.com, but bar.com has authentication code that redirects to http://www.foo.com/sso.aspx
The sso.aspx page checks for a valid ASP.NET authentication cookie in the cookies collection. If it exists, sso.aspx redirects to http://www.bar.com/page.aspx&ssoauth=[encryptedkey] (where [encryptedkey] is an MrUser's encrypted id that foo.com and bar.com have agreed on). If there is no valid ASP.NET authentication cookie, then it just redirects without the ssoauth parameter.
Bar.com does a check to avoid an infinite redirect loop and then decrypts the ssoauth value. If there is no ssoauth parameter, then MrUser is redirected to the login page, otherwise Bar.com uses the decrypted id to authenticate MrUser before it sends him on to page.aspx.
What are the potential security issues (or other types of issues) with this method?
(cite: http://blogs.neudesic.com/blogs/michael_morozov/archive/2006/03/17/72.aspx)
Edit: In response to the answers citing that the encrypted id is the same every time, and an attacker could use it to gain access - What if bar.com checks the referrer so that it only accepts ssoauth parameters from foo.com?
The first issue is that any encrypt/decrypt scheme can be figured out when it's plainly visible. You'd be better of implementing something more along the lines of a PKI encryption/decryption platform where the encryption keys are public but the decryption keys are private. The encryption will need to be suitably complex in order to increase the "time to crack", and that will require resources to perform encrypt/decrypt of the key.
The fact that you have a non-common domain will create the need to supply the encrypted piece in the header (either post or get), and pass it in plaintext. While querystring information is kept secure for the lifetime of the request (edit: assuming SSL), it is not secure from a browser history (making it accessible to common-use computers).
The worst security problem is the concept of "crack one/crack em all". If one of the servers is compromised and its encryption/decryption algorithms, salt, etc are exposed, it would be possible for an attacker to compromise all systems by generating valid encrypted SSO keys at will and on demand.
None of these problems is terribly tragic. I wouldn't implement this scheme at a bank or a medical establishment, but for a low risk site like SO or Twitter it would be perfectly acceptable. It will all come down to managing resources, risk, and gain.
Anyone can use encryptedKey to gain access as MrUser. Rather than encryption, a signing or message authentication service is needed. The authenticated message should include a nonce with the user identifier to prevent replays.
Protocols like this are hard to devise. Even TLS, which was widely used and reviewed for years has security flaws. Don't try to use an unproven authentication mechanism.
A potential problem is if ssoauth encrypted key is only the User's encrypted ID. Such a setup will result in providing the same key each time, which can therefore be both reused, by original user or worse by a third party.
One way to avoid this situation is to keep the time-of-day clocks of foo.com and bar.com servers relatively synchronized and to issue keys which include the date/time (modulo 5 minutes).
People are often tempted to use the web client's IP address as one of the elements of this encryption, but this is a bad idea, for several proxies and gateways use different public IPs within their pools to access different domains/servers.
Another way to allow for a distinct password each time is to have bar.com's redirect to
http://www.foo.com/sso.aspx
include a parameter such as
http://www.foo.com/sso.aspx?ParamForKey=some_random_number
and to use ParamForKey as part of the encryption process
There are several issues:
1) How long is the encrypted token valid? It should be valid only for a couple of seconds. Easy if all servers are on ntp. Having expiry also protects user in case they have the link containing encrypted token is left around. Validating nonce is difficult if you have many bar.com servers - you could say that having an expiry of a couple of seconds should mitigate replay.
2) Problem with SSO cross domain is single sign off. What if users sign off foo.com. The session on bar.com must be invalidated. You could XSRF bar.com logout as a hack :). You should have bar.com beacon foo.com every 15 minutes to see if user is still logged in.
3) What if user does not sign off bar.com and it is a multi-user computer and another user signs onto foo.com? You have to ensure that you if userids do not match previous user's data is not shown.
4) As someone else mentioned, you probably want a signature or HMAC on userid rather than encryption. If you do encrypt, remember to protect the integrity of the ciphertext. You do not want user A flipping bits in ciphertext to see if they can access User B's data on bar.com.
I would have the redirect over https.
Finally, as everyone said, referrers can be spoofed. Don't trust them.