Results 1 to 2 of 2

Thread: True about Sessions

  1. #1
    Senior Member
    Join Date
    Sep 2010
    ΑΡ Credit

    True about Sessions

    Almost each PHP-application uses sessions. This article examines in details realization of secure mechanism of sessions management on PHP. After the basic introduction in the architecture on which web is based, after studying the problem of condition reservation, with basic applying and sense of cookies I�ll show you some simple an effective methods which may be used for increase of security and reliability of PHP-applications needing condition reservation.
    The wrong idea is widespread that PHP provides definite security level by means of its own abilities for session management. And PHP conversely presents convenient and suitable mechanism but providing of completed solution should be done by a developer; you�ll see that there isn�t any common solution method the best for all.
    Impossibility of status reservation

    HTTP which is the web�s driving force is a protocol without status reservation. It is due to the fact that it contains nothing demanding from browser to identify itself by each request and also the permanently set connection between browser and web-server is absent which would be saved form page to page. When a user attends a web-site browser sends HTTP-request to web-server which returns a HTTP-reply. This limits interaction and represents a completed HTTP-transaction.
    As far as information exchange within web is based on HTTP status reservation within a web-application can represent a rather complicated task for developers. Cookies are the extension of HTTP-protocol which has been introduced in order to help providing reserving status HTTP-transactions but care about confidentiality encourages many users to switch off cookies� support. Information about status may be transmitted through URL however its occasional opening is a serious danger for security. In fact, the matter of status reservation itself demands from a customer to identify himself but those of us who are worried about security know that sometimes we shouldn�t trust the information sent by a customer.
    In spite of this all there are some fine methods of status reservation problem solution. Of course, there is no ideal solution as well as the method which could meet everyone�s needs. This article presents some methods which can safely provide ability for status reservation and protect from attacks based on the session such as impersonation � presenting you like someone else (forged session). At the same time you�ll study how cookies work in fact, what PHP-sessions do and what you need to forge a session.
    General idea of HTTP

    For better understanding of the status reservation problem and choosing the solution that meets your needs best it�s important to analyze a little bit architecture on which web is based � HTTP.
    Visit to demands from web-browser sending a HTTP-request to on port 80. The syntax of request is similar to following:
    GET / HTTP/1.1
    The first string is called a request string and the second parameter within it (in our example it is slash) � is the path to the resource required. Slash signifies the root of the documents tree; web-server converts it into concrete path within the file system. Apache users may be familiar with indication of this root with DocumentRoot directive. If is required, the path to resource set within the request is /path/to/script.php. If the documents tree root is defined as /usr/local/apache/htdocs, the full path to resource used by a web-server is /usr/local/apache/htdocs/path/to/script.php.
    The second string illustrates syntax of HTTP-heading. In our case this is heading �Host�; it defines domain name of the host from which a resource is required by browser. This heading according to HTTP/1.1 protocol is compulsory and helps providing virtual hosting support mechanism � a plenty of domains attended from the only IP-address (often with a common server). There are many other (optional) headings which may be included into request; addressing to them within your PHP-code may be familiar to you, for example, $_SERVER['HTTP_REFERER'] and $_SERVER['HTTP_USER_AGENT'].
    Pay your attention to the fact that there is nothing that could be used for having single meaning client recognition in the example request. Some developers use information got from TCP/IP (for example, such as IP-address) for the unique identification but this approach is connected with many difficulties. The most considerable of them is potential ability to use different IP-addresses for each request for one user (as it happens with AOL-users) and also ability to use the same IP- addresses for different users (as in the case of usage in many HTTP-proxy computer laboratories). These situations may cause such effect when one user may look as many of them and conversely many users may look as one. For secure and safe method of status providing you are to use information obtained from HTTP only.
    The first step in the problem of status reservation is the single meaning identification of each client. As far as the only reliable information that can be used for this should be obtained from HTTP-request the request itself should contain something to be used for such identification. There are some ways for realization of this but the solution that has been developed for this problem only is cookies.

    Understanding of the fact that there should be some method for single meaning clients identification resulted into an artistic solution of the problem � to the creation of cookies. It�s easy to understand cookies if you take into account that they are the HTTP-protocol extension which defines exactly what is it. Cookies are defined in RFC 2965 although the initial specification written in Netscape is closer to the one supported by industry.
    There are two HTTP-headings which are necessary for cookies mechanism realization � Set-Cookie and Cookie. Web-server includes Set-Cookie heading into reply to request in order to make browser include this cookie into the following requests. Browser within which cookies are allowed includes heading Cookie into all following requests (which correspond with conditions defined in Set-Cookie heading) until cookie becomes out-of-date (until its date expires). A typical script consists of two transactions (of four HTTP-messages):

    • Client sends a HTTP-request.
    • Server sends a HTTP-reply including Set-Cookie heading.
    • Client sends a HTTP-request including Cookie heading.
    • Server sends a HTTP-reply.

    Adding Cookie heading in the second client request (item 3) offers information which can be used by server for one meaning client identification. Also at this moment server (or PHP-script on the server�s side) may define if cookies are allowed by user. Although a user may prefer forbidding cookies it will be secure enough to suppose that user�s settings aren�t changed during the interaction with your application. This fact as it will be demonstrated soon is rather useful.
    GET- and POST-data

    There are another two methods which may be used by a client for sending data on server and these methods exist much longer than cookies. Client may place information within the URL required in the request string or directly in the path although the last case demands rather specific programming which is not discussed in this article. As an example of a request string usage we will treat following:
    GET /index.php?foo=bar HTTP/1.1
    The accepting script index.php may apply to $_GET['foo'] for getting the value of parameter �foo�. Because of this most PHP-developers speak about this data like of GET-data (others sometimes refer to them as to the data form request or to the URL-variables). The widespread reason of confusion is the fact that GET-data may exist within POST-request as well as far as they are simply a part of the URL required and don�t depend on the request�s method.
    Another method which can be used by a client for information sending is usage of HTTP-request�s contents. This method demands usage of POST as a request�s method.
    POST /index.php HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 7

    In this case accepting script index.php may apply to $_POST['foo'] for getting value of the parameter �foo�. PHP-developers usually refer to these data as to the POST-data and namely this way browser transmits data sent by the form within which method="post" is indicated.
    Generally speaking, a request may contain the both these data types:
    POST /index.php?getvar=foo HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 11
    These two optional methods of data sending in request may provide a substitution for cookies. Unlike cookies support of GET- and POST-data isn�t optional and thus these methods can also be more secure. Let�s examine a unique identifier called PHPSESSID (this is the name on default which can be changed by a PHP-application�s developer) included into the URL required:
    GET /index.php?PHPSESSID=12345 HTTP/1.1
    (in fact, integrated PHP-mechanism for session management generates session identifiers which are longer than 12345.)
    By it the same aim is achieved as by the Cookie-heading as far as client identifies himself; but this method involves more developer�s participation. As soon as a cookie is installed the duty of browser is to return it in the following requests. For the unique identifier transmission through URL a developer should provide containing the corresponding request string within all the links, form sending buttons etc. (PHP can help this if you switch on directive session.use_trans_sid). At this GET-data are displayed in URL and they are much more vulnerable than cookies. In fact, unaware users may save such an URL in the layers, send it to a friend or make with it anything they want that can accidentally open the unique identifier.
    Although POST-data may be opened with the lower grade of probability transmission of the unique identifier as a POST-variable demands doing all the user�s requests with POST-method. Usually such variant is inconvenient although design of your application can make it more viable.
    Session management

    Up to this moment I�ve discussed status which a little bit low-level notion concerning instance of one HTTP-transaction to another one. The more useful ability which should be familiar to you is session management. Session management is not only based on the ability of status reservation but also needs saving client�s data for each user�s session. These data are mostly called session data as far as they are connected with a concrete user�s session. If you use session management mechanism integrated in PHP, the session data will be saved for you (on default � in /tmp directory) and they are available within super global massive $_SESSION. A simple example of sessions� usage concerns saving the session data from one page to another. Listing 1 representing script session_start.php shows how it can be done.
    Listing 1
    $_SESSION['foo'] = 'bar';
    a href="session_continue.php">session_continue.php</a>
    If user clicks a link within session_start.php (of course, I mean a link on the page formed by this script), the accepting script session_continue.php will get an ability of success to the same session variable $_SESSION['foo']. It is shown in the Listing 2.
    Listing 2

    $_SESSION['foo']; /* bar */
    (To make the things described before happen the second script should get the session�s identifier which is generated by the first script. For this you need to switch on directive session.use_trans_sid or user should allow cookies.)
    A serious danger for security exists when you write a code similar to the displayed one without understanding of things which PHP makes for you. Without this knowledge you�ll find out that it�s difficult to checkout session errors and provide some grade of security.

    The wrong idea is widespread that the original PHP-mechanism for session management takes security measures against attacks based on sessions itself. Quite the opposite, PHP only presents a suitable mechanism for this. A developer is responsible for taking corresponding security measures. As it was mentioned before, there is no an ideal solution which would suit everyone.
    To explain danger of impersonation we�ll examine following succession of events:

    • Reliable user enters and authorizes.
    • Web-site sets a cookie PHPSESSID=12345.
    • Unreliable user enters and provides cookie PHPSESSID=12345.
    • Web-site is mistaken and thinks that Unreliable user is Reliable user in fact.

    Of course, such script demands form Unreliable user to find out somehow or simply to guess the valid PHPSESSID belonging to Reliable user. Although it seems to be unlikely � this is an example of security providing by means of obscurity. Such obscurity is not a bad thing and it can help but you need something more considerable which can offer more reliable protection from an attack like this.
    Prevention of impersonation

    There are many methods which can be used for making impersonation or other attacks based on session difficult. The common approach here is making systems possibly convenient for your legal users and possibly complicated and confusing for the attackers. This can prove to be a rather complicated balance and it depends a lot on the design of application. And thus finally you prove to be the best judge yourself.
    The simplest request which is correct from point of view of HTTP/1.1 consists as it was mentioned before of a request string and Host heading:

    GET / HTTP/1.1
    Client can transmit PHPSESSID session identifier within Cookie heading:

    GET / HTTP/1.1
    Cookie: PHPSESSID=12345
    As an alternative client can transmit session identifier within URL of request:

    GET /?PHPSESSID=12345 HTTP/1.1
    Session identifier can also be included into POST-data but usually it is not so convenient for a user and thus the least widespread.
    As far as information obtained from TCP/IP cannot be used reliably in the security mechanism reinforcement it seems that a web-developer cannot do much for prevention of impersonation. At least an attacker should present the same unique identifier that a legal user has in order to present him as this user and forge session. Thus the only protection seems to be either hiding the session identifier or making it difficult to guess (better to use the both methods).
    PHP generates a random session identifier which is nearly impossible to guess and thus you shouldn�t worry about it. It�s much more difficult to evade opening the correct identifier by an attacker as far as the greater part of responsibility for this is out of the developer�s control area.
    There are many situations which can result into opening user�s session identifier. GET-data can be mistakenly cashed, noticed by an occasional observer, saved in the layers and transmitted via e-mail. Cookies provide the most secure mechanism but users can switch of their support excluding possibility for their usage and there are some cases connected with occasional information drain from cookies onto non-sanctioned sites (look and for additional information).
    Thus a developer can be convinced that session identifier cannot be guessed but the probability of being found out by attacker is more likely independent from the method used for its transmission. Some optional means for impersonation prevention are needed.
    In fact a typical HTTP-request contains a lot of non-compulsory headings along with Host. We�ll treat following:

    GET / HTTP/1.1
    Cookie: PHPSESSID=12345
    User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U Gecko/20020916
    Accept: text/html;q=0.9, */*;q=0.1
    Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
    Accept-Language: en

    This request contains four non-compulsory headings: User-Agent, Accept, Accept- Charset and Accept-Language. Due to the fact that the headings are non-compulsory there is no sense in relying on their presence. However if browser has sent such headings the question appears: would it be secure to suppose that they�ll be present in all the following requests of the same browser? The answer is �yes� with very few exceptions. Supposing that the previous example is a request sent by a user with active session we�ll consider the next request sent soon after that:

    GET / HTTP/1.1
    Cookie: PHPSESSID=12345
    User-Agent: Mozilla/5.0 (compatible; IE 6.0 Microsoft Windows XP)
    As far as the same unique identifier is presented access to the same PHP-session will be obtained. Should we suppose that the user is the same if browser identifies itself in other way comparing with the previous interaction?
    I hope you understand that it�s undesirable but nevertheless it�s exactly the thing which will happen if you write a code which doesn�t check situations like this on purpose. Even in cases when you cannot be sure that some request is an impersonation-attack the simple demands of password enter by a user can help preventing impersonation without causing considerable difficulties for users.
    You can add a user�s browser assertion into your security model by means of a code which is similar to that presented in Listing 3.
    Listing 3

    if (
    /* Password request */
    /* The rest of a code */
    Of course, before this you need to save MD5-hash from complete user�s browser naming each time when you first start session as it is shown in Listing 4.
    Listing 4


    Although it�s not obligatory to use MD5-hash instead of complete naming of user�s browser this can provide some kind of constancy and exclude the necessity of checking correct value of $_SERVER['HTTP_USER_AGENT'] before saving it within session. As far as these data are obtained from a client you cannot trust them completely but format of MD5-hash doesn�t depend from the input data.
    Now when we�ve added user�s browser checking an attacker should make two steps in order to forge a session:

    • To get a right session identifier.
    • To provide the same User-Agent heading as by an impersonation attack.

    Although it�s possible without any doubt this is more difficult when in case of omitting the second step. Thus we�ve strengthened a bit security of the session mechanism.
    Other headings may be added the same way and you may even use combination of headings like �finger-prints�. If you add some optional secret prefix, such �prints� become nearly impossible to guess. Look example in the Listing 5.
    Listing 5

    $_SESSION['fingerprint'] = md5($fingerprint . session_id());
    Accept heading shouldn�t be used in the �finger-prints� as far as Microsoft Internet Explorer is famous with differences within this heading�s meanings in cases when a user updates a page an d when he clicks on a link.
    With difficult to guess �finger-prints� some profit is achieved without complicating this information in other way. By the mechanism existing for impersonation two steps are actually needed although the second one is much more complicated now as far as an attacker should reproduce plural headings.
    For security increase you should start switching on data further to the unique identifier. We�ll observe session management mechanism in which the unique identifier is transmitted within GET-data. If �finger-prints� generated in the previous example are also transmitted as GET-data, an attacker should make following three steps for successful session forgery:

    • Obtain a valid session identifier.
    • Render the same HTTP-headings.
    • Render valid �finger-prints�.

    If unique identifier and �finger-prints� are transmitted as GET- data it�s possible that an attacker who will be able to get an access to one of them will also be able to obtain the other one. The more secure approach is usage of two different transmission methods � GET- data and cookies. Of course, it depends on user�s settings by those who have allowed cookies may be provided optional security level. Thus if an attacker gets a unique identifier through vulnerability, the �finger-prints� will probably still remain unknown for him.
    There are many other methods which can be used in order to increase safety of your session management mechanism. We hope you�ll succeed in creating some techniques of your own. Anyway you perform a role of an expert for your own applications and so armed with good understanding of sessions you are the most suitable person for realization of optional security.
    Obscurity for unauthorized

    I would like to clear up a widespread myth about obscurity for unauthorized. The essence of this myth is following: security cannot be provided via such obscurity. As it was mentioned before, obscurity for unauthorized isn�t something which provides an adequate protection and on which you may rely. Nevertheless it doesn�t mean that security cannot be provided at any case by means of such obscurity. Quite the opposite, having secure mechanism of session management as a base obscurity for unauthorized can offer some grade of optional reliability.
    Usage of confusing variables� names for the unique identifier and �finger prints� can be rather helpful. You can also transmit false data in order to confuse a potential attacker. But you shouldn�t rely on these protection techniques but it won�t be just a waste of time if you organize some obscurity for unauthorized in the mechanism of your own. For those who haven�t got a basic understanding of sessions� security it�s probably better to support myth about obscurity for unauthorized otherwise someone may be confused believing that it provides sufficient security level.
    Important notice

    Once more (it�s important!):
    (a) if we put a print into a session (as it is done in Listing 5), we won�t get any third item and only the first two of them should be done for impersonation (this is discussed before) as far as an attacker presents a print automatically by presenting a session identifier;
    (b) (this isn�t mentioned by the author) variant of print�s transmission within cookies cannot be used at al as far as user with switched off cookies won�t be able to work; you can only transmit a print via GET and thus;
    (c) for the users with switched off cookies a session�s identifier will be transmitted via GET so if attacker succeed in passing the first item and finding out an identifier, he already knows a print and we don�t get any third item as well (author speaks about it himself);
    (d) (it�s the main and the only case when we get the third item!) for those who allowed cookies in fact �optional security level will be provided� (the author also speaks about it) but (the author doesn�t mention this) like in the item (c) transmitting print via GET demands from developer doing �with hands� such things which are done automatically in case with session�s identifier by switching on session.use_trans_sid i.e. automatically supplement links and forms with print. Besides that if you realize item (d), three is no sense in placing headings within a print (after all you may put some headings into a session by realization of the second item); it�s quite possible that a secret prefix with identifier will be enough.

  2. #2
    Join Date
    Feb 2013
    ΑΡ Credit
    Well explained ! Thanks for this !

Similar Threads

  1. Replies: 0
    Last Post: 10-31-2013, 05:21 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts