Cm3 secure code_training_1day_access_control

SECURE CODE
TRAINING
ACCESS CONTROL
DAVID CERVIGNI
IT SECURITY CONSULTANT AND
PCI CODE REVIEWER

What is Access Control?
Authorization is the process where a system determines if a specific user has
access to a resource.
https://tools.ietf.org/html/rfc2904
PIP = Policy Information Point
PDP = Policy Decision Point
PEP = Policy Enforcement Point
PAP = Policy Administration Point
PRP = Policy Retrieval Point (XACML)
*XACML stands for "eXtensible Access
Control Markup Language"

Access Control Attacks
Vertical Access Control Attacks
A standard user accessing administration functionality
Horizontal Access Control Attacks
Same role, but accessing another user's private data
Business Logic Access Control Attacks
Abuse of one or more linked activities that collectively realize a
business objective

Access Controls failure impact
• Loss of accountability
– Attackers maliciously execute actions as other users
– Attackers maliciously execute higher level actions
• Disclosure of confidential data
– Compromising admin-level accounts often results in
access to user’s confidential data
• Data tampering
– Privilege levels do not distinguish users who can only
view data and users permitted to modify data

Access Control Best Practices
• Build a centralized AuthZ mechanism
• Code to the permission, not the role
• Design AuthZ as a filter
• Deny by default, fail securely
• Server-side trusted data should drive AuthZ
• Be able to change entitlements in real time
• Design standardized data contextual AuthZ
• Build grouping for users and permissions

Access Control Anti-Patterns
• Hard-coded role checks in application code
• Lack of centralized access control logic
• Untrusted data driving access control decisions
• Access control that is “open by default”
• Lack of addressing horizontal access control in a standardized way (if
at all)
• Access control logic that needs to be manually added to every
endpoint in code
• Access Control that is “sticky” per session
• Access Control that requires per-user policy

Best Practice: Centralized AuthZ
• Define a centralized access controller
– ACLService.isAuthorized(PERMISSION_CONSTANT)
– ACLService.assertAuthorized(PERMISSION_CONSTANT)
• Access control decisions go through these simple API’s
• Centralized logic to drive policy behavior and persistence
• May contain data-driven access control policy information

Best Practice: Code to the Activity
int articleId = request.getInt(“articleId”);
if (AC.hasAccess(“article:edit:” + articleId))
{
//execute activity
}
• Code it once, never needs to change again
• Implies policy is centralized in some way
• Implies policy is persisted in some way
• Requires more design/work up front to get
right

Data Contextual Access Control
Data Contextual / Horizontal Access Control API examples:
ACLService.isAuthorized(“car:view:321”)
ACLService.assertAuthorized(“car:edit:321”)
Long form:
IsAuthorized(user, Perm.EDIT_CAR, Car.class, 321)
• Check if the user has the right role in the context of a specific object
• Protecting data at the lowest level!
9

Using a Centralized Access Controller
In Presentation Layer
if (isAuthorized(Permission.VIEW_LOG_PANEL))
{
<h2>Here are the logs</h2>
<%=Encoder.forHTMLContent(getRawLogData());%/>
}

Using a Centralized Access Controller
In Controller
try {
assertAuthorized(Permission.DELETE_USER);
deleteUser();
} catch (Exception e) {
//IDS EVENT
}

Implementation
Use a single site-wide component to check access authorization.
This includes libraries that call external authorization services and
also separate privileged logic from other application code.

Re-validaiton
If long authenticated sessions are allowed, periodically re-validate a user’s
authorization to ensure that their privileges have not changed and if they have,
log the user out and force them to re-authenticate
The application must support disabling of accounts and terminating sessions
when authorization ceases (e.g., Changes to role, employment status, business
process, etc.)

Access Control good practices examples
Don’t rely on client data
Use only trusted system objects, e.g. server side session objects, for
making access authorization decisions
Use White Listing
*Deny all access if the application cannot access its security
configuration information

Access Control bad practices examples
Use Untrusted data
• Avoid trusting request data for access control decisions
• Never make access control decisions in JavaScript
• Never make authorization decisions based solely on:
• hidden fields
• cookie values
• form parameters
• URL parameters
• anything else from the request
• Never depend on the order of values sent from the client

Consider the order or actions
Imagine the following parameters
1. http://example.com/buy?action=chooseDataPackage
2. http://example.com/buy?action=customizePackage
3. http://example.com/buy?action=makePayment
4. http://example.com/buy?action=downloadData
Can an attacker control the sequence?
Can an attacker abuse this with concurrency?

Enforce logic application flow
Enforce application logic flows to comply with business rules (AppSensor)
Monitoring:
Limit the number of transactions a single user or device can perform in a given
period of time. The transactions/time should be above the actual business
requirement, but low enough to deter automated attacks.

HARD CODED ROLES
void editProfile(User u, EditUser eu) {
if (u.isManager()) {
editUser(eu);
}
}
How to maintain that code?

HARD CODED ROLES
if ((user.isManager() ||
user.isAdministrator() ||
user.isEditor()) &&
user.id() != 1132))
{
//execute action
}

HARD CODED ROLES
• Makes “proving” the policy of an application difficult for audit or Q/A
purposes
• Any time access control policy needs to change, new code need to be
pushed
• RBAC is often not granular enough
• Fragile, easy to make mistakes

Avoid Direct Object reference
http://foo.bar/somepage?invoice=12345
How to avoid?
• Semantic validation (stateless)
• Level of (randomized) indirection (stateful implementation)

SQL Integrated Access Control
• Example Feature
http://mail.example.com/viewMessage?messageid=2356342
• This SQL would be vulnerable to tampering
select * from messages where messageid = 2356342
• Ensure the owner is referenced in the query!
select * from messages where messageid = 2356342 AND
messages.message_owner = <userid_from_session>

SECURE CODE
TRAINING
INTENSIVE COURSE
DAVID CERVIGNI
IT SECURITY CONSULTANT AND
PCI CODE REVIEWER

Cm3 secure code_training_1day_access_control

More Related Content

What's hot (9)

Similar to Cm3 secure code_training_1day_access_control (20)

More from dcervigni (9)

Recently uploaded (20)

Cm3 secure code_training_1day_access_control