On DOM Snitch internals and some of the rationales behind them

Given some of the feedback I've received during the first couple of weeks after releasing DOM Snitch, I'd like to shed more light into some of the inner workings of DOM Snitch and the rationales behind some of the decisions that were made while building the tool.


Topic 1: Why is DOM Snitch not catching security issues executing at load time through inline JavaScript?

In its current implementation, DOM Snitch is set to start running on a page as soon as the DOMWindow object is created, but before the DOM tree is built. This allows the extension to act either as soon as it's instantiated or when any of the DOM modification events get dispatched. Relying on the events, however, comes with a cost and that is the inability to know what caused the event to be dispatched in the first place; therefore resulting in the tool's inability to gather proper debug information. (I should add the disclaimer that currently DOM Snitch does not use any of the V8 debugging functionality.)


Topic 2: Is DOM Snitch using any of the experimental APIs in Chrome?

The short answer is "no". One of the early goals I set while building the tool was to stay away from experimental APIs or touching the Chromium code base as doing either one of the two will get in the way of deploying easily without changing the security posture of the user. Additionally, using unsupported functionality might result in some maintenance issues further down the line. That being said, I'm quite keen on using the chrome.experimental.debugger API should it become supported by the Chromium team.


Topic 3: On innerHTML, outerHTML, and stale pointers inside JavaScript

Stale JavaScript pointers is one side effects that really worries me when intercepting innerHTML. Although, the tool has gone through lots of iterations to getting this right, I must admit that people still find creative ways to introduce a stale pointer somewhere in their code. By giving a bit more detail on how innerHTML is intercepted, I hope that developers will pay some attention as to what may go wrong in their code from a testability perspective.

In its current version, WebKit does not reveal the internal innerHTML pointers through the getter and setter methods. As a result, by overwriting the innerHTML setter, DOM Snitch loses the value of the original pointer. To counter this, DOM Snitch re-creates the action of setting an element's innerHTML by appending a new child element and setting the child's outerHTML to the intended innerHTML value ( and as it turns out, this will force WebKit to throw away the newly created child element and replace it with whatever children that get introduced through the HTML content). You can see this implementation here.

Separating code from data... are we there yet?

Disclaimer: The opinions in this post are entirely my own and should not be associated with any current or previous employer of mine.

Mixing code and data has been a big (and I mean BIG) problem for decades in security. Setting security design flaws aside, having the ability to transform data into code has led to some of the biggest and probably most notorious examples of why software security really matters. Period.

While there is a lot of progress in handling this problem in native code (examples are plenty: GS, SafeSEH, DEP, ASLR, etc.), where does this leave web? Unlike native applications, the web has one major disadvantage: it relies heavily on parsers that help with the execution of dynamically written code. Browser security aside, there have been a few initiatives to help developers separate code from data through validating data on input or rendering data in a safe format. Although they've been done with a noble intent, I am still not convinced that this is a comprehensive enough solution. Here is why:

1. Input validation. Input validation limits the user in submitting data... both malicious and legitimate; therefore limiting the application's usability and the its users' productivity. For instance, should the folks maintaining the input validation need to be aware of every context in which their data is used (e.g. database query, JavaScript/JSON, HTML, etc.)?


2. Output encoding/escaping. Output encoding/escaping is useful for transforming data into a format that is then interpreted as data within the context where the data will be used. However, the major question here is what is the actual context in which the data will be used? In the following sample snippet the data passes through at least 2 different contexts (HTML and JavaScript):
   

   <html>
     <head>
       <script>
         document.write('<div id="' + [USER_CONTROLLED_DATA] + '">bla</div>');

   
   So naturally the question: how should the encoding/escaping be done in such cases? According to which context should the encoding/escaping be tailored?


3. Contextual escaping via templates. In most cases and if (a big IF) properly enforced, templates are a good thing to use. Needless to say, with their help development teams can streamline a solution to the problem. From that point on lint and checks on commit are the way to go. However, what if the templates are not strictly enforced? What if the development team provides special cases where data should not be escaped? What if data from upstream already comes escaped/encoded?

So where does this leave web? I suspect the biggest challenge is to separate the channels through which code and data are communicated. Avoiding or limiting the use of code parsers and eval() (or equivalents of it) for parsing data are definitely steps in the right direction...

P.S. - This post has been picking a lot on cross-site scripting as an example. However, the same logic holds for other types of security issues that arise from injection based attacks.

The evil magic of eval

Eval is a special, very powerful function in many scripting languages. JavaScript is not an exception. Although quite useful for dynamic manipulation of the existing code, any misuse of eval can cause a lot of problems and headaches. StackOverflow covers this topic well, with the exception of one very important bit: eval can get in the way of testability.

Static analysis
With JavaScript being what it is, it is easy to assume that one can painlessly audit the scripting code that runs inside the browser and understand how the client-side part of a web application functions. Well, that's not entirely true. With web applications becoming more complex, we often run into cases where we have a 60k line obfuscated code that looks a lot like this:

function a() {
 this.c = eval;
}
...
var b = a();
var d = b.c(e);

How should this be tested or audited? Simple answer: you can't really or at least not easily.

Dynamic analysis
This leads me to the next bit: what about dynamic analysis? What if we "hook" into eval and listen to the code as it goes by? As it turns out, this isn't a fool proof solution either. Eval is not exactly a function. In fact, if you ask any experienced developer, he/she may flat out tell you that eval is magic and should not be touched. To re-use the example from StackOverflow, what value should the alert box show?

var a = 10;
function foo() {
 var a = 1;
 eval("a+=1");
 alert(a);
}
foo();

As it turns out, eval is aware of the current scope from which it was called; therefore the alert box will show 2 and not 11. This is important because as you overload eval, you change the scope in which it operates (off by 1 stack frame). As a result eval will attempt to manipulate a global object and not the local one. This in turn may lead to a half baked page.

Conclusion
Although eval is very powerful, it is also overly misused for parsing and/or processing data (example: using eval to parse JSON). In a nutshell, eval provides one of the easiest ways to mix code and data... a dangerous thing to do nowadays.

P.S. - Although some browsers (namely Firefox) may allow you to overload eval at a lower level through an extension, it is not necessarily the same case with all mainstream browsers; therefore, some edge cases may be missed.

The cyber crime ecosystem

I'm re-sharing via Dexter a presentation from Albert Hui on cyber crime. It's impressive to see how far this has grown technology wise since early 2000s. It seems like yesterday when I read the reports on MyDoom experimenting with it's powers to bring DDoS against Yahoo and Google in the UK.

Anyhow, slide 9 in Albert's presentation is particularly interesting as it shows a nice overview of the players in the cyber crime underground.

Bugs, security, input validation...

Gabe has 2 very interesting posts on the topic of validating input:

Input Validation & Injection Vulnerabilities

OWASP and Input Validation

A definitely recommended read.

Domain names in Cyrilic

Veni Markovski wrote:

http://президент.рф is up and running! congratulations, Russia!!!

Well done, ICANN! We now have domain names in Cyrilic!

I suspect this will have a lot of security implications, but from an internationalization perspective, it's awesome! :)

To validate or not to validate... that is the question!

Secure development guidance preaches that all input should be validated for length, format, type, and value as appropriate. Typically, guidance stretches along the lines of validate all input that your code takes and validate accordingly. A few years ago there was a similar belief that input validation can stop cross-site scripting. Although this is partially true, full remediation of cross-site scripting is achieved by properly encoding the input data according to the context in which it is later outputted.

So here comes my question, in order to validate input properly, isn't it better to have the validation to be performed by the code that will act on it as opposed to having the validation at the trust boundary of the overall app? Example: Component1 uses Component2 for backend logic. If Component1 only passes the data straight through to Component2, my belief is that Component1 should leave the input validation to Component2. Thoughts?

SDL courses in the public

A while ago I was pointing out some interesting stats about the secure development lifecycle (SDL). Last week, Microsoft made its four core SDL training classes available to the public. The titles are:
- Basics of Secure Design Development Test
- Introduction to the Microsoft Security Development Lifecycle (SDL)
- Introduction to Threat Modeling
- Privacy in Software Development


I would encourage everyone with a bit of spare time to take a look at these courses.

The daily /.

A few interesting stories from my daily /.-ing:

1. CAPTCHA troubles
"Ticketmaster used various means to try to thwart Wiseguy’s operation, at one point switching to a service called reCAPTCHA, which is also used by Facebook. It’s a third-party CAPTCHA that feeds a CAPTCHA challenge to a site’s visitors. When a customer tries to purchase tickets, Ticketmaster’s network sends a unique code to reCAPTCHA, which then transmits a CAPTCHA challenge to the customer.

But the perpetrators were able to thwart this as well. They wrote a script that impersonated users trying to access Facebook, and downloaded hundreds of thousands of possible CAPTCHA challenges from reCAPTCHA. They identified the file ID of each CAPTCHA challenge and created a database of CAPTCHA “answers” to correspond to each ID. The bot would then identify the file ID of a challenge at Ticketmaster and feed back the corresponding answer. The bot also mimicked human behavior by occasionally making mistakes in typing the answer, the authorities said."

After having a chat with Aldwin on the topic, it seems like this might be a serious flaw in CAPTCHA (i.e. mapping a challenge to a response via identifying the filename of the CAPTCHA image). After all, CAPTCHA should allow developers to feed arbitrary text that will then get rendered on the fly.

The original article is here.


2. Nearly 60% of apps fail first security tests. Interesting number from Veracode; however, I wonder in what phase of the SDLC were those apps when they were tested. Although I agree with their argument that more work is required in educating the developers, I must also add that more tooling is necessary (e.g. code annotations, code scanning when committing code to the repository, etc.) to enable developers focus on the bigger security problems.

More on the topic here.

Plastic problems

...or Cambridge 2 PCI 0

This past week I landed on two very interesting papers that came out of Cambridge. The papers basically discuss the weaknesses of Chip & PIN and the 3-D Secure protocol for online transactions. Highly recommended read.

The 7 plagues of testing

James Whittaker was running the series of the 7 plagues of software testing on the Google Testing Blog. Since the series are at their last stretch, here is the list of plagues:
1. The Plague of Aimlessness
2. The Plague of Repetitiveness
3. The Plague of Amnesia
4. The Plague of Boredom
5. The Plague of Homelessness
6. The Plague of Blindness
7. The Plague of Entropy

There are also some additional plagues that were suggested by various readers (myself included):
- The Plague of Metrics
- The Plague of Semantics/Assumptions
- The Plague of Infinity/Endlessness/Exhaustion
- The Plague of Miscommunication/Language
- The Plague of Rigidness/Complacency

Out of the suggested bunch, I really like Roussi's notion that complacency can be the result of a product's success.

Recycling security test cases

Test cases are precious. In my day to day work, a lot of what we do is built around the notion that a test case either passes or fails. Think about the time when you withdraw money out of your favorite ATM or when your favorite application may have compromised your privacy... it's always the case of a passed or failed test case. Is there a flaw in the system? Can the system under test be put to its knees because of it?

A while ago James Whittaker talked about building repositories with reusable test cases. The whole discussion is available at the MSDN blogs. I definitely recommend reading it. As applications often have common flaws, it is beneficial to have such a repository. Tweaking the test cases to the application under test is definitely a "must-do". However, once those tweaks are done for the particular software under test, the job gets much easier.

Reflecting at the security industry, it's hard to not notice the need for James's idea to be adopted. In fact, a typical problem report from a security vendor will include the following bits:

1. What is the problem?


2. How can the problem be reproduced?


3. How can the problem be fixed?

Maybe we should start swapping the second bit with the actual executable test case? I know it's hard to do this for any type of application, but for the most common type -- Web apps -- it's certainly doable. Just look at tools like Selenium and you'll get the idea.

Phish me a Safari

Recently I decided to install Safari 4. The experience is quite nice, except I'm paranoid about phishing. Yes, I check the certificates of sites where I'm about to provide my user credentials. I check the validity of links before I click on them. I even use different browsers when browsing trusted and not so trusted sites (some might point me to this surf jacking article, but oh well).

In general, phishing is a concept that's been around for a while. It revolves around the idea to trick a user into performing an action while thinking he/she was performing another action. One of the mechanisms to do so is through obfuscating links inside a Web page. More on this can be found here.

Typically, Windows based browsers have been pretty good about revealing the URL of a link before clicking on it as this was a valid concern a few years ago (circa 2004/5). However, after switching to Mac I could say that I'm quite disappointed of not seeing any notification about the links I'm about to click on a page. In a way that goes against the secure by default concept that OS makers started adopting in 2003. Or maybe I'm just assuming too much from Apple?

P.S. - Of course, I can turn on the Safari status bar and everything will be fine; but then, would all users do the same?

Chrome and Privacy Mode

A while back I was playing around with Google Gears and Incognito mode. The test was simple: I store some data in Gears while in Incognito and try to read it while in Normal mode.

The goal
The goal of this test is quite simple: prove that privacy related data (yes, with Gears gaining momentum a lot of apps like Google Docs, Google Reader, Google Calendar, MySpace, etc. are beginning to utilize Gears' SQLite engine to cache information) that was obtained in Incognito mode will persist in Normal mode and vice-versa.

The code
Load the following code in Incognito mode:

var db = google.gears.factory.create('beta.database');
db.open('privacy-test');

db.execute('drop table if exists secret');
db.execute('create table secret (message text)');
db.execute('insert into secret values (?)', "secret message");

Load the following code in Normal mode:

var db = google.gears.factory.create('beta.database');
db.open('privacy-test');

db.execute('create table if not exists secret (message text)');
var rs = db.execute('select message from secret');
if(rs.isValidRow()) {
 alert(unescape(rs.field(0)));
}

The result
Data indeed persisted. I've posted the code for Incognito mode here and for Normal mode here.

Conclusion
Browsers' attempt to provide additional privacy to users is noble; however, this is valid only for data that the browser controls directly (e.g. cookies, browser cache). As Web applications are becoming richer in features, third party technologies like Google Gears, Flash, and Silverlight will soon need to start playing the privacy game as well if browsers are to fully allow privacy modes to users.

SSN Predictability

Carnegie Mellon has conducted a study in which they proved the predictability of Social Security Numbers in the U.S. given that date and location of birth are known. Because it is a common practice to tie an individual's SSN to his/her bank accounts, phone bills, drivers license, or practically anything, I'd love to see whether organizations in the U.S. will move more and more toward what their counter parts in Europe are doing -- namely to check the individual's social security number, the government ID number, and various other details about the individual.

This study will also be presented at BlackHat at the end of July.

Web Security 101

Mike has released a set of webcasts that cover Web security for beginners. These webcasts, including the slides, are available here. Mike's announcement and comments are available here.

Secure the textbook

Coop, a good friend of mine, is starting an initiative to revise college textbooks that teach software engineering and weed out insecure practices from them. The goal of this project is to bring security awareness throughout the entire computer science curriculum and not in just 1-2 courses. If you're interested in participating in this effort, go check out the project site.

Threat modeling: bringing it all together

There are few ways to do threat modeling. For those that are in the financial sector, it's all about business risks. For those in the technology sector, it's all about fending off direct attacks. What both approaches have in common is the fact they all try to identify and counter any event that may offset the normal order of operation within a given business process. One at the business level, while the other at the more technical level. Because both approaches have different starting and ending points, there is the risk of having gaps in the overall risk analysis process.



Why do I say this? If we look at the technical threat modeling exercise, everything begins with identifying the individual assets and the threats that affect them. The gap in this approach is that the application's business goals are not stated clear. Protecting assets is good, but why do they need to be protected? How do you convey to your higher-level management and external stakeholders that a particular asset needs protection? You simply speak in terms that can be understood by your audience: business goals. Similarly, if you look at the business risk analysis exercise, how do you ensure that the security test/audit of your application will cover all venues of attacking your system? How can you provide documentation of adequate security assessment coverage at the time of a breach? You simply provide your test plan, which is most likely derived from the attack vectors and pre-conditions in your threat model.

So what's the purpose of complicating things? As risk analysis is an essential part of ensuring any system's security, it is also essential that the report that is produced during this analysis provide meaningful, yet actionable information. Here are the steps that can help achieve that:
1. Gather information on the business goals of the system.
2. Identify the business risks that will harm those business goals.
3. Decompose the business risks into technical risks that can realize if a security breach occurs.
4. For each technical risk, build a tree of attack vectors that lead to the realization of this technical risk.
5. For each attack vector, identify the pre-conditions that are necessary for this attack vector to execute.
6. Using the attack vectors, their pre-conditions, and your knowledge of the system's attack surface, draft a document (most likely a test plan) that covers all possible venues of attack.

Thoughts?

Finding Software Insecurities through Password Policies

There are a few main security strategies to consider when using password controls within an application:
- Users should always be forced to use fairly complex passwords
- Unless used with legacy software, passwords should always be salted and hashed (even encryption doesn't cut it as there are no other valid reasons besides legacy software that mandate that passwords must be recoverable)

Earlier I landed on this blog post by Johannes Ullrich from the SANS Institute. The bit that I like the most is:

Usually, if a site is imposing [maximum] limits to your password, like the length or it doesn’t allow certain characters, you can guess that your password will be stored in the clear.

The reason is simple: If the password is hashed, then it doesn’t matter how long it is, or what characters it uses. It will always end up as a fixed length hex string.

Secure Exception Handling

Exception handling is an important part of building a secure application. Developers are often asked to pay close attention to the security context in which the exception handler executes as to ensure maximum robustness, both from performance and security point of view, of the application. The reason I mention this is a little ATM incident yesterday where a friend's debit card was swallowed in the middle of a transaction by the ATM. As my buddy provided his bank card, PIN, and withdrawal request, the ATM decided to crash -- resulting in a big red screen stating that the machine was out of order. After 3-4 minutes, while my friend was in touch with the bank's customer service, the machine restarted and started working as expected.

So what happened?
Based on the above observations it seems that the generic exception handler used in the ATM machine tells the machine to void the transaction and keep the card. There's nothing wrong with that. In fact, this seems like the most secure way to fail an operation without knowing the exact causes of this failure. However, this is where the flaw in this ATM actually is -- the gap between the source of the exception and the exception handler is too big. It's so big that the handler that catches the exception doesn't know what to do with it. This is where robustness fails and legitimate customers get pissed off. :)