Cookies & Session

Originally wanted to give a freshman in the community of PHP and the front end, the database of simple interaction and some character filtering or escaping related security issues, later boss said simply tell the python socket and the corresponding TCP connection is how to work (in the middle because the Minister understood the error and looked at the CGI two days). I feel this is enough to say one afternoon ah, this semester there is another scheduled afternoon to talk about something? Then I thought of the cookie and the session. Feel this actually quite often, but oneself is not too familiar, by the way force oneself to learn a good.

Cookies are data that a website needs to store on the user's local terminal in order to facilitate interaction with the user. This means that we can actually access and modify them locally. We are accessing the webpage by browser, so cookie management and browser are closely related. So, let's start with its construction:

When the page is accessed for the first time, the server party wants to send a cookie, which can be set by Set-cookie to append the cookie information to the HTTP header. For example, with CGI, you can refer to http://blog.csdn.net/hawksoft/article/details/43449151, writing-

print "Set-cookie:user-id = XYZ;

”

print "Set-cookie:password = XYZ123;

”

If browser receives and allows cookies, the cookie information will be stored in the appropriate place, in accordance with its own management. For example, for Chrome, it will be stored in its User Data folder.

Its cookie information chrome is generally encrypted. When using TXT to open cookies is a bunch of garbled, can only see the domain name; Open with Sublime is different. I think this is a documentary file. If you want to see the information correctly, you can see it in Chrome's settings. For the sensitive information of the user's password, chrome itself will be stored separately, the same can be seen on the settings above. In other browsers, the management of cookies will be different.

So what are the content and attributes that a cookie typically holds? Here are some examples--

Expires: Validity period. If it is 0, it is invalidated when the browser is closed

Domain:cookie the corresponding domain name. It is usually the Web page that sends the cookie, but it can also be another webpage. But it's not going to work, so don't say that.

Path: has permission to invoke this cookie. General/, that is, the file under any path

As for the contents of storage, it can be username, Password, SessionID and so on. When you visit a webpage, the browser will automatically retrieve your cookie and append it to the data if it is available (for example, expires). Of course, using Python to build a packet, you can also use the standard library to retrieve/get a cookie and attach to the request data up.

As for the session, let's first say how it works. When a user first accesses a webpage (which is accurate when not holding a valid SessionID), the server creates a session in memory corresponding to it, saving the user's existing information to compensate for the stateless nature of the HTTP. Then, the server replies with a sessionid to the user as a credential for the user's identity. The effective time of the session defaults to 20 minutes, that is, the user does not send information to the server within 20 minutes, then the server will destroy the session, the user has to re-establish a session corresponding to their own status. As for the SessionID of the session on the local cookie, it can be seen on a cookie and is normally invalidated at the end of the browsing session.

Of course, in order to interact, you can also choose session persistence.

As can be seen from the above, the session of the mechanism there is a session hijacking, session forgery and other issues, and it on a whole server, regardless of which background files, are common (because the session is in memory). But to really use it, there is a very important premise, that is, when you sessionid in effect, get the SessionID of others. So the session is still relatively safe, to use the words, need to cooperate with other means, such as XSS, middleman or inject code to leave a backdoor (such as input XXX can return username to admin sessionid). So in order to prevent this session hijacking, we can also test other, such as IP. Of course, more thoroughly avoid replay those, or use security certificates and so on is better.

In addition, some websites allow a method of URL rewriting to avoid the use of a session when the browser disables cookies. That is, after knowing that the client cannot use the cookie, the URL Exchange SessionID is used instead.

Then, the next step is to learn more about this mechanism through the vulnerability of a school-based system for verifying code bypass. This is the first two days of the evening idle boring toss, did not build a packet to really test, time is limited. Recently there are a lot of things to do, and this is actually long been played by Senior Brothers N Times (but still do not change), not much interest to play.

A description of the system Bypass verification code vulnerability in course selection

The first thing to understand is how it handles the verification code behind the scenes. Through testing, it can be found that the characteristics are

1, the submission page does not send to the login backstage entrance1.asp any data that can distinguish the verification code, for example, the verification code picture file location, src behind the string of random data, etc.

2, build a local site, when the random number is constant, every refresh, the picture will be different, and the required verification code and the number on the image is consistent

3, before and after Operation SessionID always unchanged

4, the Verification code image corresponding to the src slightly magical/code.asp?id=!!! &random=0.8535697448533028 When you manually change the random number, the picture changes and the required verification code changes.

5, when you enter the above URL, it returns not a picture, but a long string of chaotic characters. I'm not sure, personally. The reply is that no MIME type is specified for the image data.

6, when you refresh the URL, the random value is unchanged, the content has changed (the actual and 2 the same)

So you can judge the operation mechanism of this website verification code-Enter the webpage, will have the JS code to force generate random number, generate corresponding . Then, the src link of is not a file at all, but is considered to send a request with random number to code.asp that background processing website. When the background file handles this request, it will return a CAPTCHA image to browser and send the correct CAPTCHA data to the login background. If the login background determines that you are wrong, then it will be sent back to the page directly to your browser, forcing the browser to re-brush the verification code.

Then, there is a problem--backstage how to know the verification code data and pictures are corresponding to it? This intermediary is sessionid (in fact, it can be seen in other possibilities, but the latter will prove

So, here's the problem. If I get a captcha image after I open the Web page, the login background also has the correct CAPTCHA data. Then I do not use the browser, but choose to build a packet, the SessionID and verification code written in direct to the login background what? I think this will be able to successfully bypass the verification code, and then successfully carried out the demolition.

Proof: 1, open two times in Chrome under the login page, the previous open must verify the code error

2, open the login screen under Chrome, and then clear the SessionID cookie (or open it in another browser) at resource, must verify the code error

Cookies & Session