aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source/security.md
diff options
context:
space:
mode:
authorKyle Heironimus <kheironimus@decisiv.net>2014-05-01 14:09:09 -0500
committerKyle Heironimus <kheironimus@decisiv.net>2014-05-01 14:09:09 -0500
commit830839c3ec7687e9998ce68d1074ea3a535a3bba (patch)
treeab295762613e438ef5c765efbf63d841f79e17c6 /guides/source/security.md
parent0b6ac002f9afa5952c1b03aea4284e61d6239938 (diff)
downloadrails-830839c3ec7687e9998ce68d1074ea3a535a3bba.tar.gz
rails-830839c3ec7687e9998ce68d1074ea3a535a3bba.tar.bz2
rails-830839c3ec7687e9998ce68d1074ea3a535a3bba.zip
[ci skip] Security guide clarity.
Diffstat (limited to 'guides/source/security.md')
-rw-r--r--guides/source/security.md4
1 files changed, 2 insertions, 2 deletions
diff --git a/guides/source/security.md b/guides/source/security.md
index 0d347c9e4b..0f4d4e712b 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -135,8 +135,8 @@ NOTE: _Apart from stealing a user's session id, the attacker may fix a session i
This attack focuses on fixing a user's session id known to the attacker, and forcing the user's browser into using this id. It is therefore not necessary for the attacker to steal the session id afterwards. Here is how this attack works:
* The attacker creates a valid session id: They load the login page of the web application where they want to fix the session, and take the session id in the cookie from the response (see number 1 and 2 in the image).
-* They possibly maintains the session. Expiring sessions, for example every 20 minutes, greatly reduces the time-frame for attack. Therefore they access the web application from time to time in order to keep the session alive.
-* Now the attacker will force the user's browser into using this session id (see number 3 in the image). As you may not change a cookie of another domain (because of the same origin policy), the attacker has to run a JavaScript from the domain of the target web application. Injecting the JavaScript code into the application by XSS accomplishes this attack. Here is an example: `<script>document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";</script>`. Read more about XSS and injection later on.
+* They maintain the session by accessing the web application periodically in order to keep an expiring session alive.
+* The attacker forces the user's browser into using this session id (see number 3 in the image). As you may not change a cookie of another domain (because of the same origin policy), the attacker has to run a JavaScript from the domain of the target web application. Injecting the JavaScript code into the application by XSS accomplishes this attack. Here is an example: `<script>document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";</script>`. Read more about XSS and injection later on.
* The attacker lures the victim to the infected page with the JavaScript code. By viewing the page, the victim's browser will change the session id to the trap session id.
* As the new trap session is unused, the web application will require the user to authenticate.
* From now on, the victim and the attacker will co-use the web application with the same session: The session became valid and the victim didn't notice the attack.