You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Session hijack is a broader exist serious security threaten. Clients use session id to communicate with server, and we can easily to find out which is the session id when we track the communications, and used by attackers.
3
+
Session hijacking is a common yet serious security threat. Clients use session ids for validation and other purposes when communicating with servers. Unfortunately, malicious third parties can sometimes track these communications and figure out the client session id.
4
4
5
-
In the section, we are going to show you how to hijack session in order to help you understand more about session.
5
+
In this section, we are going to show you how to hijack a session for educational purposes.
6
6
7
-
## Session hijack process
7
+
## The session hijacking process
8
8
9
-
The following code is a counter for `count` variable:
9
+
The following code is a counter for the `count` variable:
10
10
11
11
func count(w http.ResponseWriter, r *http.Request) {
12
12
sess := globalSessions.SessionStart(w, r)
@@ -21,45 +21,45 @@ The following code is a counter for `count` variable:
21
21
t.Execute(w, sess.Get("countnum"))
22
22
}
23
23
24
-
The content of `count.gtpl` as follows:
24
+
The content of `count.gtpl`is as follows:
25
25
26
26
Hi. Now count:{{.}}
27
27
28
-
Then we can see following content in the browser:
28
+
We can see the following content in the browser:
29
29
30
30
31
31
32
32
Figure 6.4 count in browser.
33
33
34
-
Keep refreshing until the number becomes 6, and we open the cookies manager (I use chrome here), you should see following information:
34
+
Keep refreshing until the number becomes 6, then open the browser's cookie manager (I use chrome here). You should be able to see the following information:
35
35
36
36
37
37
38
-
Figure 6.5 cookies that saved in browser.
38
+
Figure 6.5 cookies saved in a browser.
39
39
40
-
This step is very important: open another browser (I use firefox here), copy URL to new browser, and open cookie simulator to crate a new cookie, input exactly the same value of cookie we saw.
40
+
This step is very important: open another browser (I use firefox here), copy the URL to the new browser, open a cookie simulator to create a new cookie and input exactly the same value as the cookie we saw in our first browser.
41
41
42
42
43
43
44
-
Figure 6.6 Simulate cookie.
44
+
Figure 6.6 Simulate a cookie.
45
45
46
-
Refresh page, and you'll see:
46
+
Refresh the page and you'll see the following:
47
47
48
48
49
49
50
-
Figure 6.7 hijack session succeed.
50
+
Figure 6.7 hijacking the session has succeeded.
51
51
52
-
Here we see that we can hijack session between different browsers, and same thing will happen in different computers. If you click firefox and chrome in turn, you'll see they actually modify the same counter. Because HTTP is stateless, so there is no way to know the session id from firefox is simulated, and chrome is not able to know its session id has been hijacked.
52
+
Here we see that we can hijack sessions between different browsers, and actions performed in one one browser can affect the state of a page in another browser. Because HTTP is stateless, there is no way of knowing that the session id from firefox is simulated, and chrome is also not able to know that its session id has been hijacked.
53
53
54
-
## prevent session hijack
54
+
## prevent session hijacking
55
55
56
56
### cookie only and token
57
57
58
-
Through the simple example of session hijack, you should know that it's very dangerous because attackers can do whatever they want. So how can we prevent session hijack?
58
+
Through this simple example of hijacking a session, you can see that it's very dangerous because it allows attackers to do whatever they want. So how can we prevent session hijacking?
59
59
60
-
The first step is to set session id only in cookie, instead of in URL rewrite, and set httponly property of cookie to true to restrict client script to access the session id. So the cookie cannot be accessed by XSS and it's not as easy as we showed to get session id in cookie manager.
60
+
The first step is to only set session ids in cookies, instead of in URL rewrites. Also, we should set the httponly cookie property to true. This restricts client side scripts that want access to the session id. Using these techniques, cookies cannot be accessed by XSS and it won't be as easy as we showed to get a session id from a cookie manager.
61
61
62
-
The second step is to add token in every request, like we deal with repeat form in previous sections, we add a hidden field that contains token, and verify this token to prove that the request is unique.
62
+
The second step is to add a token to every request. Similar to the way we dealt with repeat forms in previous sections, we add a hidden field that contains a token. When a request is sent to the server, we can verify this token to prove that the request is unique.
63
63
64
64
h := md5.New()
65
65
salt:="astaxie%^7&8888"
@@ -72,7 +72,7 @@ The second step is to add token in every request, like we deal with repeat form
72
72
73
73
### Session id timeout
74
74
75
-
Another solution is to add a create time for every session, and we delete the session id when it's expired and create a new one. This can prevent session hijack at some point.
75
+
Another solution is to add a create time for every session, and to replace expired session ids with new ones. This can prevent session hijacking under certain circumstances.
76
76
77
77
createtime := sess.Get("createtime")
78
78
if createtime == nil {
@@ -82,12 +82,12 @@ Another solution is to add a create time for every session, and we delete the se
82
82
sess = globalSessions.SessionStart(w, r)
83
83
}
84
84
85
-
We set a value to save the create time and check if it's expired(I set 60 seconds here), this step can avoid many of session hijack.
85
+
We set a value to save the create time and check if it's expired(I set 60 seconds here). This step can often thwart session hijacking attempts.
86
86
87
-
Combine those two solutions, you can avoid most of session hijack in your web applications. In the one hand, session id changes frequently and attacker always get expired and useless session id; in the other hand, we set session id can only be passed through cookie and the cookies is httponly, so all attacks based on URL are not working. Finally, we set MaxAge=0which means session id will not be saved in history in browsers.
87
+
Combine the two solutions above and you will be able to prevent most session hijacking attempts from succeeding. On the one hand, session ids that are frequently reset will result in an attacker always getting expired and useless session ids; on the other hand, by setting the httponly property on cookies and ensuring that session ids can only be passed via cookies, all URL based attacks are mitigated. Finally, we set `MaxAge=0` on our cookies, which means that the session ids will not be saved in the browser history.
0 commit comments