Monday evening I attended a local OWASP chapter meeting. The guest speaker was Jim Manico. Jim Manico is the person behind the OWASP Podcast and is an extremely knowledgable on the topic of security in conjunction with security for web development.

Jim started out with turning the whole problem of security around, instead of talking about top 10 threats, he wanted to present a set of top-10 defenses for web applications, emphasizing the importance of talking about remedies instead of threats.

The most important remedy is query parameterization (prepared statements with bound parameters), this addresses the number one threat and one of the most destructive go threats, also known as SQL-injection. Jim mentioned the OWASP Query Parameterization cheat sheet dedicated to this topic. The remedy is very basic, but the problem of SQL-injection does not seem to go away. On a note OWASP also has a cheat sheet dedicated to SQL-injection prevention.

Next point Jim started listing a lot of threats, which had all had the common denominator: XSS. After this followed a nice matrix of defenses. Each of the different XSS threats would exploit different vectors/vulnerabilities in primarily Javascript, the matrix did however give a nice overview of what to look for and how to defend your application.

Some basic examples of attack vectors could be:

• session hi-jacking/cookie theft: dokument.cookie and window.location
• defacement: document.body.innerHTML

Again Jim emphasized that this is hard to get and some of the more prominent and talented developers does not even see all these issues.

Jim mentioned a resource recommending: Element.setAttribute, which has several issues, due to its power.

See also:

• OWASP XSS prevention cheat sheet
• OWASP Abriged XSS prevention cheat sheet

Next up was CSRF, defenses mentioned were:

• double cookie submit
• Single Origin Policy
• randomized tokens

Jim spoke well for the randomized tokens model, where I tend to the double cookie submit model – perhaps a combination of all the defenses would be optimal. Also considering Jim himself mentioned theft of entropy based tokens using empty HTML form, so I do not see the randomized tokens model standing alone if it just have the least weakness in its implementation it is useless.

OWASP even has a cheat sheet.

Jim repeated over and over again that attacking is easy, defending is hard. An example was doing a key logger is as easy as listening for key-down/key-up events in Javascript.

Jim’s take on input validation surprised me a bit, but I could follow him. If you have your general defenses in place, input validation is actually more about data sanitization than security. Jim mentioned that handling your output is more important. Which leads me to something I have heard mentioned earlier, that you cannot trust your back-end either since you cannot be sure, how the data has been inserted/injected in the first place, so result sets for example from a database should be regarded with equal mistrust. The issue is really that the malicious data, does not do any harm until it reaches a browser again.

Jim mentioned a defense of using type strictness. I understand the concept, since it is often used in regular defensive programming and is not specific to security, but it does require developers using dynamic languages like me to think about implementing this sort of type checking as part of the application since it is not necessarily a part of the language itself – this does lead back to input validation and data sanitization, so this sort of defense does require strict handling of input data.

Jim gave some overall recommendations:

• do not let users define style (CSS), allow only pre-defined themes
• do not rely on client site defenses (javascript in browser)
• be care full with WYSIWYG editors like tinyMCE these might use plain HTML

The later does require that you parse your HTML vigorously (see also: OWASP DOM XSS cheat sheet).

On the topic of parsing, the most widely spread way of deserializing JSON is by using eval. Do use JSON parser instead.

I often see a tendency in the security community to think highly of frameworks, but with all of these new and spiffy Javascript frameworks and their plugins I really hope some of the developers to take the time to evaluate and assert the security of these.

Next up was the largest of the topics Jim covered and I think one of the topics which interests him the most currently: Access Control Design Theory.

Jim grouped the attacks in this category into the following groups:

• Vertical Access Control Attacks
• Horizontal Access Control Attacks
• Business Logic Access Control Attacks

Jim stated that the access control component has to be introduced early, deeply and globally in your system. Implement a mapping of features, policies and a central point of access.

Vertical access control attacks are you regular attacks where privilege escalation is attempted obtained. Horizontal access control attacks I guess are related to ‘Insecure Direct Object References’, which is listed on the OWASP top-10. This is where the attacker is able to obtain access to data related to other entities, by exploitation of a role-system or the like.

Jim listed some anti-patterns, many of which I see on a regular basis:

• 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
• Luckily Jim also presented some good patterns:
• Code to the activity, not the role
• Centralize access control logic
• Design access control as a filter
• Deny by default, fail securely
• Build centralized access control mechanism
• Apply same core logic to presentation and server-side access control decisions
• Server-side trusted data should drive access control

A good example of handling of operations on valuable data, was Amazon.com. If you want to:

• change credentials
• changes to entity references, like email, mobile phone number etc.

You have to re-authenticate.

One interesting problem related to the horizontal access control, which Jim shed some light on was the multiple tenants setup. This is the concept with hosted solutions or similar where you have multiple groups of users using the same system, but working on separate sets of data in a system.

I see the same challenge in regard to regular users vs. administrative users, this is an aspects with coincides very well with my ideas around use of public and private PaaS to separate deployments dedicated to regular use vs. administrative use.

Jim finished the presentation with a discussion on the problem area of passwords and the time had come to talk SSL. Jim stated that: SSL only gives us integrity, authenticity, confidentiality and repudiation. SSL is good, but SSL alone does not keep you safe. According to W3C the GET method leaks and you use it with consideration.

In general you have to formulate a set of password policies and Jim gave some recommendations:

• Allow 10-15 retries, not only 3-4, we are fighting machines not people
• At 10 bad attempts, notify user
• Utilize out of band channels: token/SMS/email
• Avoid session fixation, anonymous vs. authenticated session, do not re-use session identifiers since the unauthenticated session might already have been hi-jacked, when the user authenticates
• <input AUTOCOMPLETE=”Off”

User lock-out can be useful, but it can be straining on your resources, so you need to provide your users with ways to unlock just as you provide functionality for handling the case of forgotten passwords.

OWASP provides a forgotten password cheat sheet with more details on the topic of retrieval of forgotten passwords

I am in a position were I am designing an access control sub-system, so timing could not be better, so the evening was a blast and I am drowning in notes.