This document discusses non-invasive approaches to implementing access control on web applications and databases without changing existing code. It describes using a proxy-based approach to enforce access control policies by adding a user identifier to database queries and API requests. Various access control models like MAC and LBAC are discussed. Techniques for identifying entities and enforcing policies on SQL databases and NoSQL systems using a load balancer or WAF are presented. The document also covers using HMAC tokens to protect against access control attacks when making requests to the web application layer.

1. Non-Invasive Elimination of
Logical Access Control
Vulnerabilities in Web Applications
Denis Kolegov, Nikolay Tkachenko
National Research Tomsk State University
Information Security and Cryptography Department,
F5 Networks
Positive Hack Days V (May 26-27 2015), Moscow

2. Who We Are?
• Denis Kolegov
– PhD, associate professor at Tomsk State University Information
Security and Cryptography Department
– Sr. security test engineer at F5 Networks
• Nikolay Tkachenko
– Post-graduate student of Information Security and Cryptography
Department at Tomsk State University
– Security test engineer at F5 Networks
2

3. Access Control in Web
• Layers
– Presentation layer
– Business layer
– Data access layer
• Attacks
– Vertical and horizontal attacks
– Business logic attacks (Abuse workflow)
• Anti-patterns
– Security by obscurity
– Hard-coded role checks
– Lack of centralized access control logic
– Order specific operators
– Dependence on client-side data (cookies, hidden fields)
3

4. Typical Web-Based Architecture
4
Source: http://rubix.com/cms/app_user_typical

5. Non-invasiveness of Access Control
5
• Non-invasive implementation should not change existent application
logic and its code
• In other words, this is vulnerability mitigation without weakness
elimination
• This approach is not new and there are many examples of non-
invasive protection mechanisms in WAFs
– CSRF
– Data Manipulation
– Cookies Tampering
– Open redirect
• We will consider non-invasive approach to mitigate access control
vulnerabilities in modern web applications

6. Causes and Consequences
6
Vulnerability Attack
Weakness Threat
Insecurity
RiskUnsafety
Vladimir Kochetkov. How to Develop Secure Web Application and State in Mind?

7. Applicability
7
• Every access to every entity must be checked for
authority
• There is no possibility to eliminate access control
vulnerabilities in source code
• Access control has not been developed or has flaws
• Implementation overlay access control without source
code changes
– RBAC on MLS
– ABAC on RBAC
– MLS on DAC

8. Agenda
• Access control policies and models
• Access control on DBMS layer
• Access control on Web-server layer
• Implementation and proof of concept
8

9. Access Control Terminology
9

10. Access Control - Authorization
• Authorization is the process where a system determines
if a specific user has access to a particular resource in
accordance with given security policy
• The intent of authorization is to ensure that a user only
accesses system functionality to which he is entitled
• Complete mediation: Every subject’s access to every
object must be checked for authority
10
Jim Manico. Web Application Access Control Design

11. Access Control Policies
• Discretionary Access Control (DAC)
– Owner-controlled administration of access rights to entities
• Mandatory Access Control (MAC)
– Strict control of information flows
– LBAC, TE (DTE), MLS
• Role-based Access Control (RBAC)
– Subjects can access entities using assigned roles only
– MAC and DAC can be enforced using RBAC
• Attributed-based Access Control (ABAC)
11

12. MAC
12
• Strict control of access rights and information flows
• Types
– TE (DTE)
– LBAC (MLS)
– Themes-based
– Role-based
– Mandatory role-based (simulating MAC using RBAC)
• LBAC main requirement : Information must not flow from
entity with higher security classification to entity with
lower security classification (“top-down”)

13. MAC Policies
s2file2
s1
writem
write
file1
read
read
Low
High
TE
LBACMLS
13

14. LBAC policy
• All entities must be identified
• A lattice of security levels is given
• All entities are tagged with security classifications and all
subjects are tagged with security clearances
• A subject can access to an entity if and only if
– the subject’s security clearance allows to him to access to the
entity with given security classification
– this access will not trigger information flow from entities with
higher security classification to entities with lower security
classification
14

15. Weaknesses of Secure DBMS
based on BLP-model
15

16. Weaknesses of BLP model
• Bell-LaPadula model is still the main model for systems with MAC
• Absence of logical connections between model’s requirements
– Contradictions do not appear even if to add absurd requirement or
property to model
• Absence of state transition rules
– System Z and vulnerability in low-watermark policy
• Absence security rules prevented timing covert channels
– «clipboard» covert channel
– «hard link» covert channel
• BLP model was created for Multics
– Procfs flows
16

17. Trusted Rubix Rules
• «The simple and static nature of the Bell-LaPadula rules
provides the potential for a higher assurance of
correctness as compared to more complex and dynamic
security policy models»
• «These labels are used along with fixed Bell-LaPadula
rules to control operations»
• «In general, Bell-La Padula rules allows subjects to read
objects at lower labels and update objects at their label»
17Source: http://rubix.com/cms/sites/default/files/documentation/RX_MLS_White_Paper_6_0.pdf

18. Fixed BLP-model
• David Bell, Leonard La Padula, “Secure Computer
Systems: Mathematical Foundations,” MITRE
Corporation, March 1, 1973
• If a subject S is allowed "append" access to an object O,
a file or segment, then guaranteeing inviolability of rule
W means the system must prevent S from appending
information of a classification higher than that of O
• So the subject S can append information to the O if and
only if their levels are equal, even if the S is not
accessing any other objects
18Source: http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf

19. Trusted Rubix Rules
19Source: http://rubix.com/cms/sites/default/files/documentation/RX_MLS_White_Paper_6_0.pdf

20. Oracle OLS Read Access
20Source: https://docs.oracle.com/cd/B19306_01/network.102/b14267/accpriv.htm

21. Oracle OLS Write Access
21Source: https://docs.oracle.com/cd/B19306_01/network.102/b14267/accpriv.htm

22. Summary
• Almost all secure DBMSs based on fixed BLP-model
• They do not implement fair LBAC policy in terms
domestic computer security (e.g., DP-models)
• There are no formal models for known secure DBMSs
• DBMSs do not provide API for developing custom
access control policy
22Source: http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf

23. Access Control on DBMS Layer
23

24. Scope
24
• Account-based web applications
• DBMS types
– SQL databases (MySQL)
– NoSQL systems with REST API (OData, ElasticSearch, Solr)
• Enforcement policy model
– Network device (load balancer, WAF, reverse proxy)
– Framework module
• Goals
– DBMS access control policy enforcement
– Data layer protection

25. Known Approaches
25
• Rubix Application User
• Oracle Virtual Private Database
• Raw Level Security
• SQL Integrated Access Control
• GreenSQL Database Access Control and Firewall
• Axiomatics Dynamic Authorization

26. Classification
26
• DBMS-based
– Linter
– Rubix
– Oracle OLS
• Proxy-based
– GreenSQL
– Axiomatics Data Access Filter
• Kernel-based
– PostgreSQL
• Application-based

27. DBMS Access Control Issues
27
• How to enforce custom access control policy?
– Change source code
– Change DBMS’s engines
– Use SELinux
– SQL-query rewriting
– Kernel module
– New DBMS
• Misunderstanding of MAC conception
– Fixed Bell-LaPadula model
– Theoretically based LBAC policies usually are not implemented
in known DBMS

28. DBMS Access Control Issues
28
• The main statement of any access policy: All entities
must be identified
• Access control mechanisms are determined by
identification capabilities (columns, rows, cells)
• Entities identification in account-based systems: At least
it is necessary to identify web application subjects
(users) that initiate queries to DBMS
• Row level security can be simulated even if DBMS does
not support them

29. Approach
29
• Proxy-based
– We don't change web application and DBMS source code
– All access control rules are implemented on proxy server
– Entities' security attributes (e.g., labels) are stored on proxy
• Access control policy
• Identification: adding user’s identifier to queries
– NoSQL REST API system
– SQL database
• Access policy enforcement
– Proxy server must provide an API for getting accesses

30. Entities Identification for REST API
• Network device (WAF) for REST API databases
– URL Rewriting
• Databases with REST API
– OData
– ElasticSearch
– Solr
http://services.odata.org/OData/OData.svc/Categories(1)/Products
http://services.odata.org/user/OData/OData.svc/Categories(1)/Products
30

31. BIG-IP MAC iRule
31
Web Server
Load Balancer
Database
ElasticSearch
http://10.1.1.10:9200
https://examle.com
https://10.1.1.9:443
Web Client

32. BIG-IP Identification iRule
when HTTP_REQUEST {
set apm_cookie "[HTTP::cookie value LastMRH_Session]"
if {$apm_cookie != "" && ! [ACCESS::session exists $apm_cookie]} {
set user "[ACCESS::session data get session.logon.last.username]"
if { [HTTP::uri] starts_with “elasticsearch" && $user != "" } {
set uri "/${user}[HTTP::uri]"
HTTP::uri $uri
}
}
}
32

33. NoSQL Systems Access Control
• Ingredients
– Reverse proxy, DNAT
– URL rewriting, portal access
– Authentication modules
– iRules – Tcl-based scripting language that allows complete
programmatic access to the HTTP flows
• Assign attributes for users
– Storage: Local user DB, LDAP, Active Directory, etc.
– Attributes: groups, labels, roles, levels, etc.
• Assign attributes for resources
– Data group lists, profiles
• Enforce access control policy using iRules
33

34. Simple MAC Policy
• Checks that user is authenticated
• Retrieves user’s identifier and his classification from
session database
• Parse URL and get index’s identifier and its classification
• If user’s classification is great or equal to index’s
classification then permit request
• Note: This policy does not require control flow, by
definition
34

35. BIG-IP MAC iRule
when HTTP_REQUEST {
if {[HTTP::uri] starts_with "/elasticsearch"} {
set apm_cookie [HTTP::cookie value LastMRH_Session]
if { $apm_cookie != "" && ! [ACCESS::session exists $apm_cookie] } {
set index [getfield [HTTP::uri] "/" 3]
set indexlabel [class lookup $index "labels"]
set group "[ACCESS::session data get session.localdb.groups]"
if {($group >= $indexlabel) and ($group != "" and $indexlabel != "")} {
HTTP::header replace Host "10.1.1.10:9200“
} else {
HTTP::redirect http://lb.site.com/vdesk/hangup.php3
}
}}}}
35

36. Simulation of LBAC Policy
• An «access» concept in operation systems, classic
DBMS and HTTP systems is not the same
• Despite this, it is possible to simulate fair LBAC policies
in highly secure HTTP-based databases
• Policy
– User can get read or write accesses to any entities in accordance
with their classifications
– If user has gotten read access to entity with classification X he
will be able to get write access only to entities with the same
classification in this session
36

37. Entities Identification for SQL
37
• Hybrid (integrated) module for SQL databases
– intercepts SQL queries that are generated by each request
– finds user’s identifier
– adds user’s identifier to SQL query
SELECT name, salary FROM employee
/* user1 */SELECT name, salary FROM employee

38. Data Operations
• CRUD operations
• Embedded queries
– «INSERT INTO … VALUES((SELECT…), …)»
– «INSERT … SELECT»
– «UPDATE … SET … = (SELECT …)»
• Routines
– Triggers
– Procedures / Functions
• Cursors
38

39. Simple Query Flow
• Subject Slow accesses secret data using SELECT query
SELECT * FROM secret
39
secret
Slow
SELECT
HIGH
LOW
writem

40. Embedded Query Flow
• Subject Shigh implements memory channel using INSERT … SELECT query
– INSERT into shared (data) SELECT secret.data from secret
• Subject Slow can read secret data from table
– SELECT shared.data from shared
40
shigh
shared
select
writem
insert
secret
slow
select insert
nonsecret
HIGH
LOW
writem

41. Cursor Flow
CREATE PROCEDURE flow()
BEGIN
DECLARE done INT DEFAULT FALSE;
DECLARE a CHAR(32);
DECLARE cur1 CURSOR FOR SELECT str FROM test.high;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
OPEN cur1;
read_loop: LOOP
FETCH cur1 INTO buf;
IF done THEN
LEAVE read_loop;
END IF;
INSERT INTO test.low VALUES (buf);
END LOOP;
CLOSE cur1;
END;
41

42. SQL Database Access Control
42
• On this step we have subject’s identifiers and entities’
identifiers and we can enforce given policy
• Simple queries
• Embedded queries
• Routines
– It is more complicated case
– SAST

43. Approach to Data Protection
43
• On this step we have subject’s identity and entities’
identities and we also can try implement data layer
protection baseline using additional information
http://app.example.com/viewSalary?id=21312
/* user */SELECT * FROM salary WHERE id = 21312
SELECT * FROM salary WHERE id = 21312 AND name = user

44. Access Control on Web Server
Layer
44

45. Web Server Access Control Issues
45
• Web application access control layers
– Presentational
– Business logic
– Data access
• Workflow protection
– It was shown that almost all frameworks and WAFs do not
provide basic workflow protection
• Authorization flaws
– OWASP Top 10 2013: A4-Insecure Direct Object References

46. Known Approaches
• HMAC token protection is one of the known methods of attack
surface reducing is
• Attacks
– CSRF
– XSS
– SQLi
– CRLFi
• WAFs
– ModSecurity: HMAC Token Protection
– F5 Networks ASM: Dynamic Content Value
• This idea can also be used in non-invasive baseline access
control mechanisms
46

47. 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 (# & ; =)
47

48. • ABS is constructed by concatenating the following HTTP request’s
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
48

49. 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 with mac = h(kr, auth, time) and Ek(LP , time, kr)
– Client → Server: final request with IDs’, IDr’, mac’, Ek(LP, time, kr)
49

50. 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 mac = h(k, auth, time)
– Client → Server: final request with IDs’, IDr’, mac’
50

51. Features
51
• HMAC token mechanism protects against
– Access control entities manipulation attacks
– CSRF
– Replay attacks
– Workflow attacks
• Implementation
– Hybrid WAFs (ModSecurity)
– Network WAFs (BIG-IP ASM)
– Modular Frameworks (Django)

52. HMAC for Cookies
52
• «We are looking into options for adding hmac protection
to Cookie data. The trick here is that the data leaving the
web app in the Set-Cookie response header is not
exactly the same as the data returned in request Cookie
headers» (Trustwave SpiderLabs Blog)
• Our students (Oleg Broslavsky and Nikita Oleksov)
researched if it’s possible to apply HMAC protection for
cookies

53. Cookie Protection Protocol
• For every controlled cookie C = <key, value, path,
domain, expires, secure> we create two special cookies
• WAF_[key] protecting only cookie [key]
– Same path and domain
– Maximum expires
– Value = <controls C[value] and C[expires]>
• WAF_alpha protecting cookies’ scope
– Most common path and domain
– Maximum expires
– Value = <path and domain for each controlled cookie>
53

54. WAF_[key] Cookie Construction
• Base64(hmac(k, C[value] | C[expires]) | C[expires])
• Properties
– It is always sent with original cookie C
– C[value] part protects C from modification
– C[expires] part protects C from deletion and prolongation
– HMAC part protects WAF_C from modification
– HMAC secret key should be unique for every user, so it also
protects C and WAF_C from leakage
54

55. WAF_alpha Construction
• Base64(hmac(k, <values>)|
[C[key]|C[path]|C[domain]|C[secure] for all C])
• Properties
– It is sent on every path and domain of web application
– It contains key, path, domain and secure flag for every controlled
cookie
– Allows to control whether every controlled cookie should or
shouldn’t be sent
– HMAC part protects WAF_alpha from modification
– HMAC secret key is unique for every user
55

56. Request processing algorithm
56
Forbid request
Mark for deletion all
controlled cookies
Request contains
WAF_alpha
then else
Process every controlled
cookie
HMAC is
correct
thenelse
Mark for deletion controlled
cookies in request that are
missing in WAF_alpha and
duplicated cookies

57. Forbid request
elseSecure cookie was
sent over secure
connection
Forbid request
Domain is
correct
Cookie processing algorithm
57
Forbid requestelse
elsePath is
correct
then
Part I checks whether cookie should be sent to current location
using data in WAF_ALPHA
then
then

58. Cookie processing algorithm
58
Forbid request
Forbid request
Request contains
WAF_C
then else
HMAC is
correct
thenelse
elseExpires and
cookie value
is correct
Forbid request
Cookie is correct
then
Part II checks cookie integrity

59. Ways to forbid request
59
• When request is incorrect we should decide what to do
with this request before passing it to the web application
– Drop request
– Redirect to any safe page, e.g. homepage of web application
– Redirect to logout page
– Modify the request and pass it to the web application: delete all
incorrect controlled cookies
• Our tool redirects forbidden request to the logout page in
sessionful applications and to the safe page in
sessionless ones

60. Advantages and Restrictions
60
• Advantages
– Controls cookie integrity
– Protects cookie from being deleted
– Protects cookie from stealing
– Controls whether every controlled cookie should or
shouldn’t be sent
• Restrictions
– Requires additional traffic controlled cookies

61. Control Flow Integrity
61

62. Workflow
62
• Workflow is used to describe a system in which
actions must be performed in a particular order
• In cryptographic workflow given order is achieved
by making decryption a privileged action which can
only be executed by users which possess an
appropriate set of credentials
• There is a common cryptography workflow model
based on identity-based cryptography

63. Counter-based Protocol
63
• Simple counter-based protocol for linear workflow
• Parameters
– k - key
– url1, ..., urln – URLs
– mac1, ..., macn – attributes for access to URL and mac1=""
• Protocol actions
– Client → Server: request to resource urli, maci
– Server checks that maci = F(k, i, urli), i=i+1
– Client ← Server: response with maci= F(k, i, urli)

64. Queue-based Protocol
64
• Simple queue-based protocol for linear workflow
• Parameters
– k1, ..., kn - keys
– url1, ..., urln – URLs
– mac1, ..., macn – attributes for access to URL and mac1=""
• Protocol actions
– Client → Server: request to resource urli, maci
– Server checks that maci = F(ki, urli), i=i+1
– Client ← Server: response with maci= F(ki, urli)

65. Implementation of MAC for DBMS
MySQL and web framework Django
65

66. Architecture
66

67. MySQL Proxy
• The MySQL Proxy is an application that communicates over
the network using the MySQL network protocol and provides
communication between one or more MySQL servers and one
or more MySQL clients
• Advantages
– LUA interpreter
– Tokenizer
– Parser
67

68. MAC policy
• Labels
– Positive number
• Domain and Types
– LOAD XML
– CALL procedure/function
– LOAD DATA INFILE
• Hierarchy on DBMS entities
68

69. MySQL Proxy
69

70. Execution Flow
70

71. Identification
• Tagged SQL query example
– /* USER_ID */ SELECT * from DB.TABLE;
• SQL execution
– Cursor
– Model / Manager
• Django DB backends
– DatabaseWrapper
– CursorWrapper
71

72. Identification
72

73. SQL Query Rewrite
73
• Problems
– One account to work with DBMS
– Some DBMSs do not support row level security
• In some cases these problems together with
weaknesses in access control of the web application can
lead to the unauthorized access vulnerabilities
• Injection points examples
– SELECT .. WHERE <Statement>
– SELECT .. LEFT / RIGHT / INNER JOIN .. ON <Statement> /
USING .. WHERE <Statement>

74. SQL Query Rewrite
• Column with identifiers in protected table
SELECT title from Order
SELECT title from Order WHERE username=`USER_ID`
74

75. SQL Query Rewrite
• Column with identifier can be found in other table and
mapped to the column with primary keys of protected
table
SELECT title from Order
SELECT title FROM Order WHERE id IN (SELECT o.id FROM
Order_auth_user as o, auth_user as a WHERE o.Id_auth_user=a.id
and a.username=`USER_ID`)
75

76. SQL Query Rewrite
76

77. Resources
77
• Jim Manico. Web Application Access Control Design
• Vladimir Kochetkov. How to Develop a Secure Web
Application and State in Mind?
• Bastian Braun, Christian v. Pollak, and Joachim
Posegga. A Survey on Control-Flow Integrity Means in
Web Application Frameworks

78. 78
Denis Kolegov
dnkolegov@gmail.com
dnkolegov
Nikolay Tkachenko
notkachenko@gmail.com
afr1ka_