• sessions and cookies

      0 comments

    Face to face technical interviews, questions related to sessions and cookies will pop up regularly. Since most of the developers are familiar with these sort of basic php questions they tend to ask more tricky questions, but if you have the correct idea then it is easy to answer any of those tricky questions. Let’s have a look on potential questions,

    Where is the sessions are stored?
    Sessions are stored in server side and it is accessed by a unique id which is known as the session-id where each user/visitor is assigned when they access your website.
    How the session-id is propagated within your website?
    Basically, there are 2 methods either store it in a cookie or propagated in the URL.

    Session security questions will not be asked in an entry level interviews but, if an advanced level candidate who has experience in developing robust and secured application must know about the vulnerabilities.

    Leaking out an existing session-id to a third party is very risky if the session is filled with more important information.
    Main two methods of vulnerabilities are,
    - When the session-id is carrying in URLs
    If an external link from your site, a URL with the id might be stored in the external site’s referrer log.

    - Active attacker might listen to network traffic
    While the session-id flows over the network and if it is not encrypted an active listener might grab it. The best solution is to implement SSL and make it a must for all the users.

  • php security interview questions

      3 comments

    Consider the following code snippet. Is this code acceptable from a security standpoint?
    Assume that the $action and $data variables are designed to be accepted from the user and
    register_globals is enabled.

    <?php
    if(isUserAdmin()) {
     $isAdmin = true;
    }
    $data = validate_and_return_input($data);
    switch($action){
     case 'add':
     addSomething($data);
     break;
    case 'delete':
     if($isAdmin) {
     deleteSomething($data);
     }
    break;
    case 'edit':
     if($isAdmin) {
     editSomething($data);
     }
    break;
    default:
    print “Bad Action.”;
    }
    ?>
    

    A. Yes, it is secure. It checks for $isAdmin to be True before executing protected operations
    B. No, it is not secure because it doesn’t make sure $action is valid input
    C. No, it is not secure because $isAdmin can be hijacked by exploiting register_globals
    D. Yes, it is secure because it validates the user-data $data
    E. Both A and B

    The correct answer is C. This code is, by any means, not secure! In fact, it is the classic security exploit of PHP scripts using the register_globals configuration directive. The problem lies in the $isAdmin variable: although this is clearly a Boolean value, it is only set in the event that the user is an Admin and not set at all if the user is not. Because register_globals is enabled, by simply appending that variable to the end of the URL as a GET parameter, a malicious user could easily impersonate an administrator:

    http://www.example.com/action.php?action=delete&data=foo&isAdmin=1