Tag Info

Hot answers tagged

8

From the perspective of the site developer, you should use the following: Adopt SSL: use SSL sitewide. Set the secure flag on all cookies. This will ensure that they are only sent over a SSL connection. Turn on HSTS. This will ensure that session cookies are only accessible via SSL, and protect you from eavesdropping and man-in-the-middle attacks. ...


7

First, please read upon session fixation attacks and make sure you understand how they work. You didn't give us the information that is needed to determine whether standard session fixation attacks will work; all of that information is relevant to other attacks, but not to session fixation. The fundamental characteristic of a session fixation attack is ...


6

The specific scenario can be prevented easily: Create a new sessionid on login. Please note that the issues exists across domains, if the sessionid is an url-parameter. Generating a new sesionid, however, not be sufficient to prevent other kinds of attack: Once Alice is logged in and visits Mallory's subdomain, will the cookie be transmitted? It is common ...


6

That's not how a session fixation attack works. The attacker must first trick the user into visiting the website using a predetermined session. For example, I could trick you into clicking a shortened link http://example.com/index.php?PHPSSIDE=BLAHBLAHBLAH. If you login to example.com now, your session will be identified by BLAHBLAHBLAH. I'd then simply use ...


5

You can also add session.entropy_length = 512 and session.use_trans_sid = 0. Also do not forget to: use https regenerate session id if you change users permissions. do sessions time out. Time depends on your app. It has nothing to do with security, but why not to change session.hash_bits_per_character to 6. The bigger the number, the shorter the string ...


5

If you are using a reasonable web framework (one that has a halfway decent design), you do not need to encrypt session data. That really ought to be the responsibility of the framework. However, if you are using PHP, you are not using a reasonable web framework. PHP is a problem child for security, in so many ways. One of those ways is that, by default, ...


5

You don't need to encrypt it. At most, encryption is a form of obfuscation. You're putting the key on the same system as the data, so it can always be found and extracted. If you're set on encrypting it, it's actually quite possible to do it within PHP without modifying every use of $_SESSION. You can use the SessionHandler class to override normal handling ...


5

The solution to avoid the session fixation is simple changing session ID. bool session_regenerate_id([bool $delOldSession = false]) will replace the current session id with a new one, and keep the current session information. Adding parameter true: session_regenerate_id(true) deletes old esssion. If you don't delete old sessions, then your web-application ...


5

The safest answer is to use entirely different domains. If you use subdomains of the same domain, start by learning about the details of the possible attacks. There's a lot already written about this, on this site. See, e.g., What cookie attacks are possible between computers in related DNS domains (*.example.com)? , Preventing insecure webapp on ...


4

The attacker never logs into the site with their credentials, they just access a page to get the session id, so while they pass on a valid session id to the victim, they do not pass on an authenticated session. When the victim logs into the site, the session is now authenticated and the attacker can access it as the victim.


3

It doesn't make a lot of sense if the key is stored serverside - but the key might come from the browser / user. It's more dificult to access the key in this scenario (provided it's over SSL) even with some access to the server / source code. Session data may be stored on the filesystem / in a database - and hence persist in backups. Also, on a shared ...


3

No. It is not enough to just use the application framework's session management features and do nothing more. It is definitely a good idea to use the application framework's session management (do not roll your own session management) -- but you will need to take some additional steps as well. The exact division of responsibility between the developer and ...


2

In general, the most fatal mistake you can make when developing an application is attempting to "roll your own", when such functionally is already provided by your platform (like trying to re-implement ssl). Vulnerabilities are inevitable, by relying on your platform you are gaining the strength of the community to audit your security for FREE, the ...


2

I'll answer my own question since I haven't seen this practice be encouraged in various SDKs and code samples. Here is my theory: Upon clicking the "sign in" button on the Relying Party (RP), two things should happen: Write a random value to a SECURE HTTPOnly domain cookie Then have the IDP redirect back to ...


2

I'd say that it depends on your use case. If you look at an HTTP POST request there are essentially three areas where data can be placed, the headers, the URL and the request body. If we're ruling out putting the token in the request body or in the URL, that leaves us with the request headers as a place to put the authentication token. There are existing ...


2

How to avoid session fixation (Login CSRF) by MitM attack without HSTS? You can't. You need to have your site in the HSTS preloaded lists to avoid this type of MITM attack otherwise the attacker could MITM the first connection and set the session cookies to fixate it to the attacker's session. However, I cannot use HSTS because the same domain needs ...


2

Interesting question. What your are describing is an environment, where the attacker mounts a man-in-the-middle attack, where it can read and modify the users HTTP traffic but not HTTPS traffic. This excludes SSLStrip-like attacks and SSL man-the-middle so you might look here for ideas on how to detect these kind of attacks at the server. In the environment ...


1

Here are few extra steps which can make session secure. Limit the session validity for accepted short time Always transmit session ids on SSL/TLS Never send session ids on URLs (Use post method) Make Strong CSRF tokens and Make sure CSRF tokens are validated. You can find more on https://www.owasp.org/index.php/Session_Management_Cheat_Sheet ...


1

Is there any way we can avoid it? Yes, you could have a rolling session key. i.e. the server will generate a new Session ID to store in the cookie every n number of requests. The Set-Cookie header will only be sent once, so if there are two browsers logged into the same session, one of them will be using the old, invalid session. You could have a small ...


1

Your content is going into an HTML attribute, encoded in a URL. That gives you two possible forms of encoding: URL-encoding: %2F. Although this should in principle work, both IIS and Apache block the use of URL-encoded slashes due to some past security issues. HTML-encoding: /, or rather as it is itself in a URL, %26%2347%3B. (Although... since ...


1

SHA(auth-session-cookie) is only useful if the underlying value of auth-session-cookie is itself sufficiently large and random. Also auth-session-cookie should be short lived (eg. 2 minutes), so state isn't valid indefinitely to reduce the risk of replay attacks.


1

Doing this in the browser with JavaScript is insecure and inefficient. As you have already mentioned, if the User Agent doesn't execute JavaScript then the user is just going to be sat on your 403 Forbidden page. If you're going to return a 403 response to a user, why not just return a 301 and make some use of the response? This is a bad user experience at ...


1

login button on http://www.foo.co.uk that when clicked opens up an iframe I would strongly recommend that this be changed such that the current page redirects to the SSL site or opens a new window - as a user I want to see 'https' in the address bar before I enter any authentication tokens! Yes, using the same session id on both systems is insecure and ...


1

As you've noted already creating this token on the unencrypted www site will essentially remove the benefit of running over SSL for the secure site as an attacker can just sniff the token when it's transferred to the unencrypted site and then use it on the encrypted site to masquerade as the user. Also having a link from the unencrypted site to the ...



Only top voted, non community-wiki answers of a minimum length are eligible