# 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. 

{% hint style="danger" %}
Each Protected Page/Asset loader, should have a prolog that verifies the users ability to access the requested data. 
{% endhint %}

{% tabs %}
{% tab title="PHP Prolog" %}

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

//protected asset/data
```

{% endtab %}
{% endtabs %}

## 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.&#x20;

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.&#x20;

## 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.&#x20;

* 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);
* J**ava:**\
  oldHttpSession=HttpServletRequest.getSession();\
  oldHttpSession.invalidate();\
  newHttpSession=HttpServletRequest.getSession(true);
* **.NET:**&#x20;

  Session.Abandon();\
  Response.Cookies.Add(new HttpCookie("ASP.NET\_SessionId", ""));


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.hackbook.io/web-application-hacking/web-techniques/authorization.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.