Access Control – Adventures in the programming jungle

Book review: Iron-Clad Java Building Secure Web Applications

5 September, 201626 October, 2016Adrian Citu

This a review of the Iron-Clad Java: Building Secure Web Applications book.

(My) Conclusion

I will start with the conclusion because it’s maybe the most important part of this review.

For me this is a must read book if you want to write more robust (web and non web) applications in Java, it covers a very large panel of topics from the basics of securing a web application using HTTP/S response headers to handling the encryption of sensitive informations in the right way.

Chapter 1: Web Application Security Basics

This chapter is an introduction to the security of web application and it can be split in 2 different types of items.

The first type of items is what I would call “low-hanging fruits” or how you could improve the security of your application with a very small effort:

The use of HTTP/S POST request method is advised over the use of HTTP/S GET. In the case of POST the parameters are embedded in the request body, so the parameters are not stored and visible in the browser history and if used over HTTPS are opaques to a possible attacker.
The use of the HTTP/S response headers:
- Cache-Control – directive that instructs the browser how should cache the data.
- Strict-Transport-Security – response header that force the browser to alway use the HTTPS protocol. This it can protect against protocol downgrade attacks and cookie hijacking.
- X-Frame-Options – response header that can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
- X-XSS-Protection – response header that can help stop some XSS atacks (this is implemented and recognized only by Microsoft IE products).

The second types of items are more complex topics like the input validation and security controls. For this items the authors just scratch the surface because all of this items will be treated in more details in the future chapters of the book.

Chapter 2: Authentication and Session Management

This chapter is about how a secure authentication feature should work; under the authentication topic is included the login process, session management, password storage and the identity federation.

The first part is presenting the general workflow of login and session management (see next picture) and for every step of the workflow some dos and don’t are described.

The second part of the chapter is about common attacks on the authentication and for each kind of attack a solution to mitigated is also presented. This part of the chapter is strongly inspired from the OWASP Session Management Cheat Sheet which is rather normal because one of the authors (Jim Manico) is the project manager of the OWASP Cheat Sheet Series.

If you want to have a quick view of this chapter you can take a look to the presentation Authentication and Session Management done by Jim.

Even if you are not implementing an authentication framework for you application, you could still find good advices that can be applied to other web applications; like the use of the use of the secured and http-only attributes for cookies and the increase of the session ID length.

Chapter 3: Access Control

The chapter is about the advantages and pitfalls of implementing an authorization framework and can be split in three parts.

The first part describes the goal of an authorization framework and defines some core terms:

subject : the service making the request
subject attributes : the attributes that defines the service making the request.
group : basic organizational structure
role : a functional abstraction that uniquely describe system collaborators with similar or unique duties.
object : data being operating on.
object attributes : the attributes that defines the type of object being operating on.
access control rules : decision that need to be made to determine if a subject is allowed to access an object.
policy enforcement point : the place in code where the access control check is made.
policy decision point : the engine that takes the subject, subject attributes, object, object attributes and evaluates them to make an access control decision.
policy administration point : administrative entry in the access control system.

The second part of the chapter describes some access control (positive) patterns and anti-patterns.

Some of the (positive) access control patterns: have a centralized policy enforcement point and policy decision point (not spread through the entire code), all the authorization decisions should be taken on server-side only (never trust the client), the changes in the access control rules should be done dynamically (should not be necessary to recompile or restart/redeploy the application).

For the anti-patterns, some of then are just opposite of the (positive) patterns : hard-coded policy (opposite of “changes in the access control rules should be done dynamically”), adding the access control manually to every endpoint (opposite of have a centralized policy enforcement point and policy decision point)

Others anti-patterns are around the idea of never trusting the client: do not use request data to make access control policy decisions and fail open (the control access framework should cope with wrong or missing parameters coming from the client).

The third part of the chapter is about different approaches (actually two) to implement an access control framework. The most used approach is RBAC (Role Based Access Control) and is implemented by some well knows Java access control frameworks like Apache Shiro and Spring Security. The most important limitation of RBAC is the difficulty of implementing data-specific/contextual access control. The use of ABAC (Attribute Based Access Control) paradigm can solve the data-specific/contextual access control but there are no mature frameworks on the market implementing this.

Chapter 4: Cross-Site Scripting Defense

This chapter is about the most common vulnerability found across the web and have two parts; the presentation of different types of cross-site scripting (XSS) and the way to defend against it.

XSS is a type of attack that consists in including untrusted data into the victim (web) browser. There are three types of XSS:

reflected XSS (non persistent) – the attacker tampers the HTTP request to submit malicious JavaScript code. Reflected attacks are delivered to victims via e-mail messages, or on some other web site. When a user clicks on a malicious link, submitting a specially crafted form the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server.
stored XSS (persistent XSS) – the malicious script is stored on the server hosting the vulnerable web application (usually in the database) and it is served later to other users of the web application when the users are loading the vulnerable page. In this case the victim does not require to take any attacker-initiated action.
DOM-based XSS – the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser.

For the defense techniques the big picture is that the input validation and output encoding should fix (almost) all the problems but very often various factors needs to be considered when deciding the defense technique.

Some projects are presented for the input validation (OWASP Java Encoder Project) and output encoding (OWASP HTML Sanitizer, OWSP AntiSamy).

Chapter 5: Cross-Site Request Forgery Defense and Clickjacking

synchronizer token pattern – an anti-CSRF token is created and stored in the user session and in a hidden field on subsequent form submits. At every submit the server checks the token from the session matches the one submitted from the form. Tomcat 6+ implements this pattern; for more infos please see CSRF Protection Filter.
double-cookie submit pattern – when a user authenticates to a site, the site should generate a (cryptographically strong) pseudo-random value and set it as a cookie on the user’s machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. The AngularJS framework implements this pattern out of the box; see Cross Site Request Forgery (XSRF) Protection
challenge/response pattern – the solution consists in forcing the user a value known only to him in order to complete the action.

Chapter 6: Protecting Sensitive Data

This chapter is articulated around three topics; how to protect (sensitive) data in transit, how to protect (sensitive) data at rest and the generation of secure random numbers.

How to protect the data in transit

The standard way to protect data in transit is by use of cryptographic protocol Transport Layer Security (TLS). In the case of web applications all the low level details are handled by the web server/application server and by the client browser but if you need a secure communications channel programmatically you can use the Java Secure Sockets Extension (JSSE). The authors recommendations for the cipher suites is to use the JSSE defaults.

Another topic treated by the authors is about the certificate and key management in Java. The notions of trustore and keystore are very well explained and examples about how to use the keytool tool are provided. Last but not least examples about how to manipulate the trustores and keystores programmatically are also provided.

How to protect data at rest

The goal is how to securely store the data but in a reversible way, so the data must be wrapped in protection when is stored and the protection must be unwrapped later when it is used.

For this kind of scenarios, the authors are focusing on Keyczar which is a (open source) framework created by Google Security Team having as goal to make it easier and safer the use cryptography for the developers. The developers should not be able to inadvertently expose key material, use weak key lengths or deprecated algorithms, or improperly use cryptographic modes.

Examples are provided about how to use Keyczar for encryption (symmetric and asymmetric) and for signing purposes.

Generation of secure random numbers

Last topic of the chapter is about the Java support for the generation of secure random numbers like the optimal way of using the java.security.SecureRandom (knowing that the implementation depends on the underlying platform) and the new cryptographic features of Java8 (enhance of the revocation certificate checking, TLS Server name indication extension).

Chapter 7: SQL Injection and other injection attacks

This chapter is dedicated to the injections attacks; the sql injection being treated in more details that the other types of injection.

SQL injection

The sql injection mechanism and the usual defenses are very well explained. What is interesting is that the authors are proposing solutions to limit the impact of SQL injections when the “classical” solution of query parametrization cannot be applied (in the case of legacy applications for example): the use of input validation, the use of database permissions and the verification of the number of results.

Other types of injections

XML injection, JSON-Based injection and command injection are very briefly presented and the main takeaways are the following ones:

use a safe parser (like JSON.parse) when parsing untrusted JSON
when received untrusted XML, an XML schema should be applied to ensure proper XML structure.
when XML query language (XPath) is intermixed with untrusted data, query parametrization or encoding is necessary.

Chapter 8: Safe File Upload and File I/O

The chapter speaks about how to safety treat files coming from external sources and to protect against attacks like file path injection, null byte injection, quota overloaded Dos.

The main takeaways are the following ones: validate the filenames (reject filenames containing dangerous characters like “/” or “\”), setting a per-user upload quota, save the file to a non-accessible directory, create a filename reference map to link the actual file name to a machine generated name and use this generated file name.

Chapter 9: Logging, Error Handling and Intrusion Detection

Logging

What should be be logged: what happened, who did it, when it happened, what data have been modified, and what should not be logged: sensitive information like sessions IDs, personal informations.

Some logging frameworks for security are presented like OWASP ESAPI Logging and Logback. If you are interested in more details about the security logging you can check OWASP Logging Cheat Sheet.

Error Handling

On the error handling the main idea is to not leak to the external world stacktraces that could give valuable information about your application/infrastructure to an attacker. It is possible to prevent this by registering to the application level static pages for each type of error code or by exception type.

Intrusion Detection

The last part of the chapter is about techniques to help monitor end detect and defend against different types of attacks. Besides the “craft yourself” solutions, the authors also re presenting the OWASP AppSensor application.

Chapter 10: Secure Software Development Lifecycle

The last chapter is about the SSDLC (Secure Software Development Life Cycle) and how the security could be included in each steps of development cycle. For me this chapter is not the best one but if you are interested about this topic I highly recommend the Software Security: Building Security in book (you can read my own review of the book here, here and here).

(My) CISSP Notes – Access control

22 October, 201229 October, 2012Adrian Citu

Note: This notes were made using the following books: “CISPP Study Guide” and “CISSP for dummies”.

The purpose of access control is to allow authorized users access to appropriate data and deny access to unauthorized users and the mission and purpose of access control is to protect the confidentiality, integrity, and availability of data. Access control is performed by implementing strong technical, physical and administrative measures. Access control protect against threats such as unauthorized access, inappropriate modification of data, loss of confidentiality.

Basic concepts of access control

CIA triad and his opposite (DAD) – see (My) CISSP Notes – Information Security Governance and Risk Management

A subject is an active entity on a data system. Most examples of subjects involve people accessing data files. However, running computer programs are subjects as well. A Dynamic Link Library file or a Perl script that updates database files with new information is also a subject.

An object is any passive data within the system. Objects can range from databases to text files. The important thing remember about objects is that they are passive within the system. They do not manipulate other objects.

Access control systems provide three essential services:

Authentication – determines whether a subject can log in.
Authorization – determines what an subject can do.
Accountability – describes the ability to determine which actions each user performed on a system.

Access control models

Discretionary Access Control (DAC)

Discretionary Access Control (DAC) gives subjects full control of objects they have been given access to, including sharing the objects with other subjects. Subjects are empowered and control their data.

Standard UNIX and Windows operating systems use DAC for filesystems.

Access control list (ACLs) provides a flexible method for applying discretionary access controls. An ACL lists the specific rights and permissions that are assigned to a subject fora given object.
Role-Based Access Control (RBAC) is another method for implementing discretionary access controls. RBAC defines how information is accessed on a system based on the role of the subject. A role could be a nurse, a backup administrator, a help desk technician, etc. Subjects are grouped into roles and each defined role has access permissions based upon the role, not the individual.

Major disadvantages of DAC include:

lack of centralized administration.
dependence of security-conscious resource owners.
difficult auditing because of the large volume of log entries that can be generated.

Mandatory Access Control (MAC)

Mandatory Access Control (MAC) is system-enforced access control based on subject’s clearance and object’s labels. Subjects and Objects have clearances and labels, respectively, such as confidential, secret, and top secret.

A subject may access an object only if the subject’s clearance is equal to or greater than the object’s label. Subjects cannot share objects with other subjects who lack the proper clearance, or “write down” objects to a lower classification level (such as from top secret to secret). MAC systems are usually focused on preserving the confidentiality of data.

In MAC, the system determines the access policy.

Common MACs models includes Bell-La Padula, Biba, Clark-Wilson; for more infos about these models please see : (My) CISSP Notes – Security Architecture and Design .

Major disadvantages of MAC control techniques include:

lack of flexibility.
difficulty in implementing and programming.

Access control administration

An organization must choose the type of access control model : DAC or MAC. After choosing a model, the organization must select and implement different access control technologies and techniques. What is left to work out is how the organization will administer the access control model. Access control administration comes in two basic flavors: centralized and decentralized.

Centralized access models systems maintains user account information in a central location. Centralized access control systems allow organizations to implement a more consistent, comprehensive security policy, but they may not be practical in large organizations.

Exemples of centralized access control systems and protocols commonly used for authentication of remote users:

LDAP
RAS – Remote Access Service servers utilize the Point-to-Point Protocol (PPP) to encapsulate IP packets. PPP incorporates the following three authentication protocols: PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), EAP (Extensible Authentication Protocol).
RADIUS – The Remote Authentication Dial In User Service protocol is a third-party authentication system. RADIUS is described in RFCs 2865 and 2866, and uses the User Datagram Protocol (UDP) ports 1812 (authentication) and 1813 (accounting).
Diameter is RADIUS’ successor, designed to provide an improved Authentication, Authorization, and Accounting (AAA) framework. RADIUS provides limited accountability, and has problems with flexibility, scalability, reliability, and security. Diameter also uses Attribute Value Pairs, but supports many more: while RADIUS uses 8 bits for the AVP field (allowing 256 total possible AVPs), Diameter uses 32 bits for the AVP field (allowing billions of potential AVPs). This makes Diameter more flexible, allowing support for mobile remote users, for example.
TACACS -The Terminal Access Controller Access Control System is a centralized access control system that requires users to send an ID and static (reusable) password for authentication. TACACS uses UDP port 49 (and may also use TCP).

Decentralized access control allows IT administration to occur closer to the mission and operations of the organization. In decentralized access control, an organization spans multiple locations, and the local sites support and maintain independent systems, access control databases, and data. Decentralized access control is also called distributed access control.

Access control defensive categories and types

Access control is achieved throughout an entire et of control which , identified by purpose, include;

preventive controls, for reducing risks.
detective controls, for identifying violations and incidents.
corrective controls, for remedying violations and incidents.
deterrent controls, for discouraging violations.
recovery controls, for restoring systems and informations.
compensating controls, for providing alternative ways of achieving a task.

These access control types can fall into one of three categories: administrative, technical, or physical.

Administrative (also called directive) controls are implemented by creating and following organizational policy, procedure, or regulation.
Technical controls are implemented using software, hardware, or firmware that restricts logical access on an information technology system.
Physical controls are implemented with physical devices, such as locks, fences, gates, security guards, etc.

Preventive controls prevents actions from occurring.

Detective controls are controls that alert during or after a successful attack.

Corrective controls work by “correcting” a damaged system or process. The corrective access control typically works hand in hand with detective access controls.

After a security incident has occurred, recovery controls may need to be taken in order to restore functionality of the system and organization.

The connection between corrective and recovery controls is important to understand. For example, let us say a user downloads a Trojan horse. A corrective control may be the antivirus software “quarantine.” If the quarantine does not correct the problem, then a recovery control may be implemented to reload software and rebuild the compromised system.

Deterrent controls deter users from performing actions on a system. Examples include a “beware of dog” sign:

A compensating control is an additional security control put in place to compensate for weaknesses in other controls.

Here are more clear-cut examples:

Preventive

Physical: Lock, mantrap.
Technical: Firewall.
Administrative: Pre-employment drug screening.

Detective

Physical: CCTV, light (used to see an intruder).
Technical: IDS.
Administrative: Post-employment random drug tests.

Deterrent

Physical: “Beware of dog” sign, light (deterring a physical attack).
Administrative: Sanction policy.

Authentication methods

A key concept for implementing any type of access control is controlling the proper authentication of subjects within the IT system.

There are three basic authentication methods:

something you know – requires testing the subject with some sort of challenge and response where the subject must respond with a knowledgeable answer.
something you have – requires that users posses something, such as a token, which proves they are an authenticated user.
something you are – is biometrics, which uses physical characteristics as a means of identification or authentication.
A fourth type of authentication is some place you are – describes location-based access control using technologies such as the GPS, IP address-based geo location. these controls can deny access if the subject is in incorrect location.

Biometric Enrollment and Throughput

Enrollment describes the process of registering with a biometric system: creating an account for the first time.

Throughput describes the process of authenticating to a biometric system.

Three metrics are used to judge biometric accuracy:

the False Reject Rate (FRR) or Type I error- a false rejection occurs when an authorized subject is rejected by the biometric system as unauthorized.
the False Accept Rate (FAR) or Type II error- a false acceptance occurs when an unauthorized subject is accepted as valid.
the Crossover Error Rate (CER) – describes the point where the False Reject Rate (FRR) and False Accept Rate (FAR) are equal. CER is also known as the Equal Error Rate (EER). The Crossover Error Rate describes the overall accuracy of a biometric system.

Types of biometric control

Fingerprints are the most widely used biometric control available today.

A retina scan is a laser scan of the capillaries which feed the retina of the back of the eye.

An iris scan is a passive biometric control. A camera takes a picture of the iris (the colored portion of the eye) and then compares photos within the authentication database.

In hand geometry biometric control, measurements are taken from specific points on the subject’s hand: “The devices use a simple concept of measuring and recording the length, width, thickness, and surface area of an individual’s hand while guided on a plate.”

Keyboard dynamics refers to how hard a person presses each key and the rhythm by which the keys are pressed.

Dynamic signatures measure the process by which someone signs his/her name. This process is similar to keyboard dynamics, except that this method measures the handwriting of the subjects while they sign their name.

A voice print measures the subject’s tone of voice while stating a specific sentence or phrase. This type of access control is vulnerable to replay attacks (replaying a recorded voice), so other access controls must be implemented along with the voice print.

Facial scan technology has greatly improved over the last few years. Facial scanning (also called facial recognition) is the process of passively taking a picture of a subject’s face and comparing that picture to a list stored in a database.

Access control technologies

There are several technologies used for the implementation of access control.

Single Sign-On (SSO) allows multiple systems to use a central authentication server (AS). This allows users to authenticate once, and then access multiple, different systems.

SSO is an important access control and can offer the following benefits:

Improved user productivity.
Improved developer productivity – SSO provides developers with a common authentication framework.
Simplified administration.

The disadvantages of SSO are listed below and must be considered before implementing SSO on a system:

Difficult to retrofit.
Unattended desktop. For example a malicious user could gain access to user’s resources if the user walks away from his machine and leaves in log in.
Single point of attack .

SSO is commonly implemented by third-party ticket-based solutions including Kerberos, SESAME or KryptoKnight.

Kerberos is a third-party authentication service that may be used to support Single Sign-On. Kerberos uses secret key encryption and provides mutual authentication of both clients and servers. It protects against network sniffing and replay attacks.

Kerberos has the following components:

Principal: Client (user) or service
Realm: A logical Kerberos network
Ticket: Data that authenticates a principal’s identity
Credentials: a ticket and a service key
KDC: Key Distribution Center, which authenticates principals
TGS: Ticket Granting Service
TGT: Ticket Granting Ticket
C/S: Client Server, regarding communications between the two

Kerberos provides mutual authentication of client and server.Kerberos mitigates replay attacks (where attackers sniff Kerberos credentials and replay them on the network) via the use of timestamps.

The primary weakness of Kerberos is that the KDC stores the plaintext keys of all principals (clients and servers). A compromise of the KDC (physical or electronic) can lead to the compromise of every key in the Kerberos realm. The KDC and TGS are also single points of failure.

SESAME is Secure European System for Applications in a Multi-vendor Environment, a single sign-on system that supports heterogeneous environments.

“SESAME adds to Kerberos: heterogeneity, sophisticated access control features, scalability of public key systems, better manageability, audit and delegation.”20 Of those improvements, the addition of public key (asymmetric) encryption is the most compelling. It addresses one of the biggest weaknesses in Kerberos: the plaintext storage of symmetric keys.

Assessing access control

A number of processes exist to assess the effectiveness of access control. Tests with a narrower scope include penetration tests, vulnerability assessments, and security audits.

Penetration tests

Penetration tests may include the following tests:

Network (Internet)
Network (internal or DMZ)
Wardialing
Wireless
Physical (attempt to gain entrance into a facility or room)

A zero-knowledge (also called black box) test is “blind”; the penetration tester begins with no external or trusted information, and begins the attack with public information only.

A full-knowledge test (also called crystal-box) provides internal information to the penetration tester, including network diagrams, policies and procedures, and sometimes reports from previous penetration testers.

Penetration testers use the following methodology:

Planning
Reconnaissance
Scanning (also called enumeration)
Vulnerability assessment
Exploitation
Reporting

Vulnerability testing

Vulnerability scanning (also called vulnerability testing) scans a network or system for a list of predefined vulnerabilities such as system misconfiguration, outdated software, or a lack of patching. A vulnerability testing tool such as Nessus (http://www.nessus.org) or OpenVAS (http://www.openvas.org) may be used to identify the vulnerabilities.

Security audit

A security audit is a test against a published standard. Organizations may be audited for PCI (Payment Card Industry) compliance, for example. PCI includes many required controls, such as firewalls, specific access control models, and wireless encryption.