Google Data » Christopher Semturs

Do Know Evil

Christopher Semturs — Thu, 06 May 2010 10:00:00 +0000

Web Application Exploits and Defenses

by Bruce Leban in Google Kirkland

http://google-gruyere.appspot.com/

If you want your application to be as secure as possible, you need to learn how Evil People think. And you'll want to use that knowledge to do penetration testing: attacking your own application to try to find bugs.

To help you understand how applications can be attacked and how to protect them from attack, we've created the “Web Application Exploits and Defenses” codelab. The codelab uses Gruyere, a small, cheesy, web application that is full of real world bugs.

In the codelab, you'll learn how to:

Attack a web application to find and exploit common web security vulnerabilities.
Avoid and fix these common bugs.

Gruyere is chock full of cool features, and the more features an application has the larger the attack surface. Your application probably has features just like these:

Can you match each feature to the vulnerability that it exposes and the exploit it enables?

Feature

New template language
HTML allowed in snippets
File upload capability
AJAX
Web-based admin console

Vulnerability

Cross Site Scripting (XSS)
Cross Site Request Forgery (XSRF)
Cross Site Script Inclusion (XSSI)
Path traversal
Client-state manipulation

Exploit

Information disclosure
Elevation of privilege
Denial of Service (DoS)
Spoofing
Code execution

Ha! Tricked you! Each of these features introduces multiple vulnerabilities. And each vulnerability can be exploited in multiple ways. The codelab walks you step by step through each vulnerability, with progressive hints guiding you on how to find them, how to exploit them and how to avoid them.

Here are some examples of fictitious attacks against Google applications. Do you recognize them? (answers below)

http://www.gmail.com/?search=in:spam+%3Cscript%3EmoveToInbox(selectAll())%3C/script%3E
http://www.blogger.com/delete-blog.g
http://www.picasa.com/../../../../../../../etc/passwd
http://www.youtube.com/admin?v=Vr0oK3gMzK&action=rickroll
http://checkout.google.com/buy?order=4815162342&total=0.01

Are you sure that your application isn't vulnerable to similar attacks!?

Check out the Toilet-Friendly Version for the answers

TotT: Making a Perfect Matcher

Christopher Semturs — Mon, 05 Oct 2009 08:45:00 +0000

by Zhanyong G. Mock Wan in Google Kirkland

In the previous episode, we showed how Google C++ Mocking Framework matchers can make both your test code and your test output readable. What if you cannot find the right matcher for the task?

Don't settle for anything less than perfect. It's easy to create a matcher that does exactly what you want, either by composing from existing matchers or by writing one from scratch.

The simplest composite matcher is Not(m), which negates matcher m as you may have guessed. We also have AnyOf(m1, ..., mn) for OR-ing and AllOf(m1, ..., mn) for AND-ing. Combining them wisely and you can get a lot done. For example,

EXPECT_THAT(new_code, AnyOf(StartsWith(“// Tests”)),
Not(ContainsRegex(“TODO.*intern”))));

could generate a message like:

Expected: (starts with “// Tests”) or
(doesn't contain regular expression “TODO.*intern”)
Actual: “/* TODO: hire an intern. */ int main() {}”

If the matcher expression gets too complex, or your matcher logic cannot be expressed in terms of existing matchers, you can use plain C++. The MATCHER macro lets you define a named matcher:

MATCHER(IsEven, “”) { return (arg % 2) == 0; }

allows you to write EXPECT_THAT(paren_num, IsEven()) to verify that paren_num is divisible by two. The special variable arg refers to the value being validated (paren_num in this case) – it is not a global variable.

You can put any code between {} to validate arg, as long as it returns a bool value.

The empty string “” tells Google C++ Mocking Framework to automatically generate the matcher's description from its name (therefore you'll see “Expected: is even” when the match fails). As long as you pick a descriptive name, you get a good description for free.

You can also give multiple parameters to a matcher, or customize its description. The code:

// P2 means the matcher has 2 parameters. Their names are low and high.

MATCHER_P2(InClosedRange, low, high, “is in range [%(low)s, %(high)s]”) {
return low <= arg && arg <= high;
}
...
EXPECT_THAT(my_age, InClosedRange(adult_min, penalty_to_withdraw_401k));

may print:

Expected: is in range [18, 60]
Actual: 2

(No, that's not my real age.) Note how you can use Python-style interpolation in the description string to print the matcher parameters.
You may wonder why we haven't seen any types in the examples. Rest assured that all the code we showed you is type-safe. Google C++ Mocking Framework uses compiler type inference to “write” the matcher parameter types for you, so that you can spend the time on actually writing tests – or finding your perfect match.

Toilet-Friendly Version

TotT: Literate Testing With Matchers

Christopher Semturs — Tue, 29 Sep 2009 17:57:00 +0000

By Zhanyong G. Mock Wan in Google Kirkland

Alright, it sounds like a good idea to verify that matchmakers can read and write. How does this concern us programmers, though?
Actually, we are talking about a way of writing tests here – a way that makes both the test code and its output read like English (hence “literate”). The key to this technique is matchers, which are predicates that know how to describe themselves. For example, in Google C++ Mocking Framework, ContainsRegex("Ahcho+!") is a matcher that matches any string that has the regular expression "Ahcho+!" in it. Therefore, it matches "Ahchoo!" and "Ahchoooo! Sorry.", but not "Aha!".
What's this to do with test readability, anyway? It turns out that matchers, whose names are usually verb phrases, lend themselves easily to an assertion style that resembles natural languages. Namely, the assertion

EXPECT_THAT(value, matcher);

succeeds if value matches matcher. For example,

#include
using ::testing::Contains;
...
EXPECT_THAT(GetUserList(), Contains(admin_id));

verifies that the result of GetUserList() contains the administrator.

Now, pretend the punctuations aren't there in the last C++ statement and read it. See what I mean?

Better yet, when an EXPECT_THAT assertion fails, it will print an informative message that includes the expression being validated, its value, and the property we expect it to have – thanks to a matcher's ability to describe itself in human-friendly language. Therefore, not only is the test code readable, the test output it generates is readable too. For instance, the above example might produce:

Value of: GetUserList()
Expected: contains "yoko"
Actual: { "john", "paul", "george", "ringo" }

This message contains relevant information for diagnosing the problem, often without having to use a debugger.
To get the same effect without using a matcher, you'd have to write something like:

std::vector users = GetUserList();
EXPECT_TRUE(VectorContains(users, admin_id))
<< " GetUserList() returns " << users
<< " and admin_id is " << admin_id;

which is harder to write and less clear than the one-liner we saw earlier.

Google C++ Mocking Framework (http://code.google.com/p/googlemock/) provides dozens of matchers for validating many kinds of values: numbers, strings, STL containers, structs, etc. They all produce friendly and informative messages. See http://code.google.com/p/googlemock/wiki/CheatSheet to learn more. If you cannot
find one that matches (pun intended) your need, you can either combine existing matchers, or define your own from scratch. Both are quite easy to do. We'll show you how in another episode. Stay tuned!

Toilet-friendly version

TotT: Testing GWT without GwtTestCase

Christopher Semturs — Sat, 08 Aug 2009 07:53:00 +0000

Because GWT (Google Web Toolkit) is new and exciting it's easy to forget the lessons on clean GUI code structure that have been accumulated over nearly thirty years.

GwtTestCase is good for testing UI-specific code in JavaScript. If you find yourself using GwtTestCase for testing non-ui client-side logic you may not have a clear View/Presenter separation. Separating the View and the Presenter allows for more modular, more easily tested code with shorter test times. Model View Presenter was introduced in another episode back in February. Here's how to apply it to a GWT app.

Defining terms:

Server – a completely standard backend with no dependency on GWT.

Model – the data model. May be shared between the client and server side, or if appropriate you might have a different model for the client side. It has no dependency on GWT.

View – the display. Classes in the view wrap GWT widgets, hiding them from the rest of your code. They contain no logic, no state, and are easy to mock.

Presenter – all the client side logic and state; it talks to the server and tells the view what to do. It uses RPC mechanisms from GWT but no widgets.

The Presenter, which contains all the interesting client-side code is fully testable in Java!

public void testRefreshPersonListButtonWasClicked() {
IMocksControl easyMockContext = EasyMock.createControl()
mockServer = easyMockContext.createMock(Server.class);
mockView = easyMockContext.createMock(View.class);
List franz = Lists.newArrayList(new Person("Franz", "Mayer"));
mockServer.getPersonList(AsyncCallbackSuccessMatcher>reportSuccess(franz)));
mockView.clearPersonList());
mockView.addPerson(“Franz”, “Mayer”);
easyMockContext.replay();
presenter.refreshPersonListButtonClicked();
easyMockContext.verify();
}

Testing failure cases is now as easy as changing expectations. By swapping in the following expectations, the above test goes from testing success to testing that after two server failures, we show an error message.

mockServer.getPersonList(AsyncCallbackFailureMatcher>reportFailure(failedExpn))
expectLastCall().times(2); // Ensure the presenter tries twice

mockView.showErrorMessage(“Sorry, please try again later”));

You'll still need an end-to-end test. But all your logic can be tested in small and fast tests.

The Source Code for the Matchers is open-sourced and can be downloaded here: AsyncCallbackSuccessMatcher.java - AsyncCallbackFailureMatcher.java.

Consider using Test Driven Development (TDD) to develop the presenter. It tends to result in higher test coverage, faster and more relevant tests, as well as a better code structure.

This week's episode by David Morgan, Christopher Semturs and Nicolas Wettstein based in Zürich, Switzerland – having a real Mountain View

Toilet-friendly version

AsyncCallbackSuccessMatcher.java

AsyncCallbackFailureMatcher.java.