Hot answers tagged

11

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. ...


9

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.


8

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 ...


8

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 ...


7

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 ...


7

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, ...


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 ...


6

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 ...


6

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

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

Is SSL/TSL and HttpOnly enough to be sure that a session cannot be hijacked? Those are the must dos, and they offer good (but not perfect) protection. See question four. Is there a way to use client IP addresses as an extra layer of protection? Just checking that a session ID is used by the IP that created it will break your site for a lot of users, ...


3

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 to ...


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 ...


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 ...


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 https://www.host.com/account/signin?csrf=...


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'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

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 ...


2

The $_SESSION variable in PHP is a temporary block of memory assigned to each specific user separately. Its purpose is not to be secure, it is meant to store session information. If you are thinking of using it to store long lasting data, or data that needs to comply with the CIA triad I suggest you look into something else. There are variables in PHP's ...


2

This is a session fixation vulnerability, even if it may be relatively difficult to exploit. You make a lot of assumptions before you conclude that everything is fine. Your assumptions are: “An attacker cannot set a cookie in the victim's browser, except through an XSS vulnerability.” “There are no XSS vulnerabilities anywhere in my application.” “IP ...


2

Your scheme is problematic from a UX and Security standpoint. Bad UX, If implemented properly a user who logs in on their phone will immediately be logged out on their computer, or whatever. There are several other problematic cases where users who shouldn't be logged out are logged out. That's not horrible, but depending on the use of your application is ...


2

Mallory doesn't want Alice's session id. Mallory wants Alice to perform actions as herself, but while the website thinks she's Mallory. Like use her credit card to buy something she thinks she'll get, but which will actually be credited to Mallory. There are several vectors for this attack. The one you mention, cookie-less sessions with the session id in ...


1

Since both implementations rely on the security of the cookie to protect the session, that means the comparison mostly relies on the qualities of the cookie values (meaning if you steal either cookie you're in). Both values are basically a value encrypted against a key stored server-side. Sessions uses a random value encrypted against the machine key, and ...


1

It looks like you have copied the example attacks directly from the OWASP page on Session Fixation. To clarify - these are intended to be examples specific to a system that has another vulnerability besides Session Fixation (XSS, HTML Injection, etc) - these are not attacks that are likely to work in any real world situation. If you wanted to execute this ...


1

Q1 - Preventing Session Fixation - MAC or Hash? Q2 - What is lost if the MAC is replaced by unkeyed hash? Q3 - Is there a weakness with this approach (of replacing MAC with a hash)? You identified the drawback of key management with using MAC across multiple servers whereas with unkeyed hash the only drawback is increased risk of session forgery due to ...


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

Reading http://tools.ietf.org/html/rfc6749#section-4.1.1, this is what I interpret: The client (in this case, the server with an account that Mallory is fixating) directs the user-agent to an OAuth request. state has been determined by the client, and is passed with the request, and will be passed back when the user-agent is sent to redirect_uri with an ...


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

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 https://...


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 ...



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