Authorization

Insecure Direct Object Reference

This is when a software engineer accidently lets users access objects that they should not have access to. Typically there wont be a way to view the object with normal user behavior but perhaps changing URL param values can force the site to respond with data that you cannot typically see.

Each Protected Page/Asset loader, should have a prolog that verifies the users ability to access the requested data.

PHP Prolog

<?
    session_start();
    if(!isset($_SESSION['logged'])){
        header("Location: http://www.site.com/login");
        die();
    }
?>

//protected asset/data

Failure to Restrict URL Access

This vulnerability is when an a user can guess and access a page that they should not be able to. An example would be that they cannot pass the admin login portal but they can access pages within the admin portal if they just navigate to the locations.

In some cases, functions to use may be specified by a passed URL param. Sometimes a developer may assume that a user would not edit/guess the functions. If the backend does not check the user who made the function call then this is a vulnerability. For example maybe after a login works a request is made with the ?auth=true and when it failed, ?auth=false. If we are able to edit this and access pages then the Authorization is broken.

Session ID

A secure session ID, if handled correctly, must also have the following properties:

• Real Random Gen

• Valid only for a single session instance

• Have a TTL

Storage

If on a compromised system, check for session tokens that are still active. Look at browser history for session tokens/creds in URLs. Check Browser Cookie cache, Check Session Storage and Local storage, check web/proxy/waf logs. In some cases you may be able to packet sniff session cookies. Also look into web-app session files if you have read access.

• PHP: The php.ini file will have the session.save_path. The files will be named sess_<sessionID>.

• Tomcat: Session file is SESSIONS.ser

• ASP.NET: process named aspnet_wp.exe, or dedicated win service, or in MSSQL DB.

Session Fixation

Here you create the session ID and get the user to navigate to your CSRF link so that you know what session they are using and can then hijack it or preload actions into the link. In some cases you can also generate new sessionIDs and save them to the web-app which will force an update to the user with the known sessionID.

Invalidation methods:

• Php: session_regenerate_id(true);

• Java: oldHttpSession=HttpServletRequest.getSession(); oldHttpSession.invalidate(); newHttpSession=HttpServletRequest.getSession(true);

• .NET:

  Session.Abandon(); Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));