Getting OWASP Top 10 Right with Dynamic Authorization

This is a joint post with Gunnar Peterson. Gunnar (@oneraindrop) is a Managing Principal at Arctec Group. He focuses on security architecture consulting and training. Experience includes Associate Editor for IEEE Security & Privacy Journal, a contributor to the DHS Build Security In portal on software security, a Microsoft MVP for security, an IANS Research Faculty member, a Securosis Contributing Analyst, and a Visiting Scientist at Carnegie Mellon Software Engineering Institute.

The non-stop drum beat of data breaches and non-stop security issues show that a new approach to security is required writ large. Application security can be improved through the use of access control. However not all application security issues are best solved with classic access control schemes.

Attackers are intelligent and adaptable. For them, the access control scheme is the beginning of the game not the end. Determined attackers seek out access control models and then find holes that they can leverage. Security is a business with a very long list of issues and requirements. The spreadsheets are miles long. This makes it essential to find reusable solution patterns that can address multiple problems. The use of XACML-based fine-grained ABAC solutions provides one such opportunity.

In this blog post (which summarizes a white paper and a webinar on this topic), we show how to achieve concrete improvement on many of the most critical issues in the OWASP Top Ten list of high priority vulnerabilities.

The OWASP Top Ten reflects the most common and highest impact vulnerabilities on the Web. The current practices that we are using have limited success in closing out these vulnerabilities, SQL Injection, Cross Site Scripting (XSS), Cross Site Request Forgery(CSRF), Clickjacking, and the like are still high priority issues what our industry is doing to prevent them is not working – it is time for a new approach.

The vulnerability classes in the OWASP Top Ten can be broken down into two types – 1) malicious code that exploits vectors (these include SQL Injection and XSS) and 2) vulnerable targets where access control is not designed or implemented correctly. In the white paper we explore how to attack the problems that plague web applications with a new approach to access control. XACML and ABAC offer a standard approach towards addressing the second issue of access control and can be used to help mitigate exploitable vulnerabilities in web applications and web services. In fact when you step back and look at the list, half of the issues are directly linked to access control issues. 

OWASP Top Ten Issue #




Broken Authentication & Session Management

Compromised access keys, tokens, cre- dentials, and tokens used in access control protocols


Insecure Direct Object Reference

Authorization code allows for attacker to gain direct access to back end resources


Security Misconfiguration

Application, server, or platform lacks security hardening


Missing Function Level Access Control

Authorization code not in place, security by obscurity


Cross Site Request Forgery

Application does not implement fine grained access control and grants access to malicious third party


There are a lot of example documents on the advantages of Attribute Based Access Control (ABAC) and how moving towards a policy based, dynamic and fine-grained approach to access control pays dividends to systems. In the white paper we take a different approach and look at code examples of documented vulnerabilities showing where XACML and ABAC can help organizations address security issues. For the set of examples, we used OWASP’s WebGoat to demonstrate where and how the access control engine can improve the application’s security. All of the ALFA code is available for download off of the Axiomatics site.

WebGoat Example – Using an Access Control Matrix

This example has four users – Moe, Larry, Curly and Shemp. The users select from a set of resources such as Public Share, Time Card Entry and Account Manager.

Larry public

Larry should not be allowed to access the Account Manager resource because Larry is not assigned to the required role. However in the WebGoat example, Larry’s access is allowed in the application.

larry accountmanager

The main issue is that the application does not implement the access control correctly to verify whether the user Larry is authorized to access Account Manager resource. The application’s vulnerability can be addressed by adding a Policy Enforcement Point (PEP) component to the WebGoat application that sends a XACML access control decision request to the PDP to ensure that the application requests are verified against an access control policy. The following code shows the changed WebGoat code.

private boolean isAllowed(String user, String resource) { 	List roles = getRoles(user); 	List resources = getResources(roles);         //return (resources.contains(resource));         PDPConnection pdpConn = PDPConnectionFactory.getPDPConnection();         xacmlRequestBuilder xacmlRequestBuilder = new xacmlRequestBuilder(3);         xacmlRequestBuilder.addSubjectAttribute("app_id", "webgoat")         	.addActionAttribute(Constants.ACTION_ID, "ACMatrix")         	.addSubjectAttribute(Constants.SUBJECT_ID,user)         	.addResourceAttribute(Constants.RESOURCE_ID,resource);         for (int i = 0; i < roles.size(); i++) {         	// In typical XACML, the role would be fetched from LDAP etc.         	// Here this is not followed to keep the example stand-alone         	xacmlRequestBuilder.addSubjectAttribute("role", (String)roles.get(i));         } 	Request xacmlRequest =	xacmlRequestBuilder.buildRequest(); 	SDKResponse response1 = pdpConn.evaluate(xacmlRequest); 	if(response1.getDecision() == 0 ){ 		return true; 	} 	else 	{ 		return false; 	} }  

The policy that is invoked by the PDP checks to ensure that the user has the attribute “role” whose value has been set to “Admin” before the user is allowed to access the Account Manager resource. The ALFA code for the rule to implement the Access Control matrix implied in the WebGoar example is as follows.

rule { 	permit 	target clause resourceId == "Account Manager" 	condition stringIsIn("Admin", role) } 

Download the OWASP white paper for more example of using XACML policies to solve security issues highlighted in the WebGoat examples.

Why Authorization Matters

Application security needs improvements along two lines. To ease administration and simplify development, ac- cess control should tend to be more configured and not coded. Security is not just about access control. Security must also deal with actively malicious users, must enforce default deny rulesets that set application level rules governing parameters, resource access, data, and fields.

Attackers are efficient in finding where application weakspots live. They will explore all the forms, fields, parameters and data. Attackers drill down to very fine grained parts of the system to find and exploit weaknesses. As defenders we must find and deploy security tools like XACML and ABAC that can defend to the same level of granularity that attackers use to try to breach out systems.

Authorization matters in general and specifically how you choose to build authorization into your code matters. Quality development resources are scarce. When developers disentangle authorization logic from code and externalise them, there is less ongoing pressure to maintain authorization policies and rules in code, and more flexibility to build out new functionality and features.


We have only scratched the surface of what can be done with XACML and ABAC. In fact there are many more advanced access control scenarios that can be handled with these standards and technologies. XACML and ABAC can go way deeper on these advanced authorization use cases. For example, role based access control can usually be improved by adding fine-grained attributes to access policy.

Given the breadth and depth of security issues developers need flexible tools that can address a wide variety of vulnerabilities and close out as many critical security issues as possible.

If your system is only using hard coded access control logic, try using these examples to learn how to pull some authorization logic out of the code and into a policy based configuration.

If your system is using roles or groups in configuration files to govern access, try using these examples to see how to use dynamic attributes to make more fine-grained decisions.

If your system is already using Attribute Based Access control, try to see how authorization policies can be used not just for access control but also to block attacks like Forced Browsing, Parameter Tampering, CSRF and others.

You may also be interested in the webinar Gunnar, Gerry Gebel and I did on this topic as well as the blog post written by Gunnar on this topic.


Related Articles

Meeting today’s dynamic authorization and access challenges: The Axiomatics story | Dynamically Speaking
Dynamically Speaking
For more than 15 years, Axiomatics has worked with companies worldwide to define and deliver solutions to the most complex authorization and access challenge. In...
Getting started with Zero Trust using dynamic authorization | Dynamically Speaking
Dynamically Speaking
Zero Trust. It’s everywhere. It’s a methodology that’s been around for years, and we are now seeing a significant uptick in the number of enterprises...
The case for dynamic authorization in banking and finance
Attribute Based Access Control (ABAC)
More than other organizations, banks, and financial institutions face the highest levels of scrutiny when it comes to how they protect critical assets and sensitive...