Cookie, Session, Data Transfer and SQL Injection

You may misunderstand what is a cookie and what is a session. Because my knowledge is very limited in the PHP world, I’d like to share my experience in other world.

Generally speaking, cookie is cookie, session is session, they are totally different topics. So hijacking cookie has nothing to do with hijacking session.

What are session, cookie and data transfer?

“A session is defined as the period of time that a unique user interacts with a Web application.” - from MSDN

It looks like that it is a cookie, isn’t it? No, it’s not. It only defines a behaviour or an event. So many kinds of technologies could be used for SESSION.

Cookie is just one of them, which is proved to be unsafe already. From many years ago, we’ve stopped using cookie to store any confidential information in the production environment. I think even a rookie programmer will know this basic rule.

If cookie is not safe, what we use to store information more safely? From .Net 1.1, we use two kinds of Cookieless session consisting of .Net Session and SQL Server Session. Both of them use the different technology from Cookie.

.Net Session is HTTP only and stored at server side so that it cannot be read from javascript. Although it could be changed by javascript, it is nearly impossible for a hacker to guess an unique session id. ASP.NET is designed with the XSS weakness in mind - the session ID is suitably long and hard to predict.

.Net Session is an in-memory session, which is not very stable. For a more reliable requirement, a SQL Server session could be used instead.

I remembered Nigle mentioned we could write some session information in the URL parameters. Actually it is out of the scope of SESSION. I think it belongs to how to transfer data between different pages. Obviously SESSION is very suitable for this purpose. However, it doesn’t mean session is the only way to achieve our goal. We could use sever transfer and http request as well. That’s why I mentioned GET and Post in today’s seminar. Because embed session information in the URL using GET is not very safe as well.

As for the XSS example demonstrated by George, it is very helpful and useful. But I cannot understand why you all thought it is a serious problem at that moment. After the meeting, finally I realized because you are using PHP rather than .Net. I didn’t have concern about this problem before, because such a behaviour is not allowed by default in I write a simple page with cookies for test.

Then launch the website, create a cookie and try to access the value through the url.

An exception will be thrown out as the picture.

If try to write script to a text box and post it to the server, an exception will be thrown out as well.

As you can see, both of them are server errors which means the server has validated them automatically.

If we meet these errors in the testing, we should know what the problem is easily.

Now I show you another example. In the first page, I write a HTTP only session (.Net inproc session), and then browse to the second page.

I write a script to try to read the cookie. It can only read the content of the normal cookie here.

I don’t think only .Net has the solution for HTTP Only session and server validation. There also should be similar solutions in PHP. However, Page redirection ≠ Data transfer ≠ Session ≠ Cookie

SQL Injection

We have an interesting discussion about how to write a correct sql query code at the meeting. I used to use Parameter Collection or Parameter Statement in C# and Java. I know it can prevent this kind of injection but I don’t know why. So I did some research using my diablo time.

From MSDN, it said SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code.

So how can it achieve this?

Here are some interesting posts which explain this.

From MYSQL 5.0, there is a similar solution as MS SQLSERVER.

I reckon PDO uses MYSQL’s mechanism to prevent injection, because it must use database-specific PDO driver to access a database server.