Web Application Exploits and Defenses (Part 5)

Look at all the files installed with Gruyere. Are there any files that shouldn't be there?

Look for a .gtl file that isn't referenced anywhere.

To exploit, you can use the debug dump page dump.gtl to display the contents of the database via the following URL:

https://google-gruyere.appspot.com/123/dump.gtl

To fix, always make sure debug features are not installed. In this case, delete dump.gtl. This is an example of the kind of debug feature that might be left in an application by mistake. If a debug feature like this is necessary, then it needs to be carefully locked down: only admin users should have access and only requests from debug IP addresses should be accepted.

This exploit exposes the users' passwords. Passwords should never be stored in cleartext. Instead, you should use password hashing. The idea is that to authenticate a user, you don't need to know their password, only be convinced that the user knows it. When the user sets their password, you store only a cryptographic hash of the password and a salt value. When the user re-enters their password later, you recompute the hash and if it matches you conclude the password is correct. If an attacker obtains the hash value, it's very difficult for them to reverse that to find the original password. (Which is a good thing, since despite lots of advice to the contrary, users frequently use the same weak passwords for multiple sites.)

You can upload a file of any type.

To exploit, Gruyere allows the user to upload files of any type, including .gtl files. So the attacker can simply upload their own copy of dump.gtl or a similar file and than access it. In fact, as noted earlier, hosting arbitrary content on the server is a major security risk whether it's HTML, JavaScript, Flash or something else. Allowing a file with an unknown file type may lead to a security hole in the future.

To fix, we should do several things:

1. Only files that are part of Gruyere should be treated as templates.
2. Don't store user uploaded files in the same place as application files.
3. Consider limiting the types of files that can be uploaded (via a whitelist).

You can insert something in your private snippet which will display the contents of the database.

This attack is closely related to the previous ones. There is a bug in the code that expands templates that you can exploit.

There is a defect in Gruyere's template expansion code that reparses expanded variables. Specifically, when expanding a block it expands variables in the block. Then it parses the block as a template and expands variables again,

{{_db:pprint}}

To fix, modify the template code so it never reparses inserted variable values. The defect in the code is due to the fact that ExpandTemplate calls _ExpandBlocks followed by _ExpandVariables, but _ExpandBlocks calls ExpandTemplate on nested blocks. So if a variable is expanded inside a nested block and contains something that looks like a variable template, it will get expanded a second time. That sounds complicated because it is complicated. Parsing blocks and variables separately is a fundamental flaw in the design of the expander, so the fix is non-trivial.

This exploit is possible because the template language allows arbitrary database access. It would be safer if the templates were only allowed to access data specifically provided to them. For example, a template could have an associated database query and only the data matched by that query would be passed to the template. This would limit the scope of a bug like this to data that the user was already allowed to access.

Can you figure out how to change the value of the private snippet in the AJAX response?

What happens if a JSON object has a duplicate key value?

To exploit, create a user named private_snippet and create at least one snippet. The JSON response will then be {'private_snippet' : <user's private snippet>, ..., 'private_snippet' : <attacker's snippet>} and the attacker's snippet replaces the user's.

To fix, the AJAX code needs to make sure that the data only goes where it's supposed to go. The flaw here is that the JSON structure is not robust. A better structure would be [<private_snippet>, {<user> : <snippet>,...}].

Look at what the script does to replace the snippets on the page. Can you get it to replace the sign in link?

Look at the AJAX code to see how it replaces each snippet, and then look at the structure of the home page and see if you can see what else you might be able to replace. (You can't just replace the sign in link. You'll have to replace a bit more.)

To exploit, create a user named menu-right and publish a snippet that looks exactly like the right side of the menu bar.

<a href='https://evil.example.com/login'>Sign in</a>
| <a href='https://evil.example.com/newaccount.gtl'>Sign up</a>

If the user is already logged in, the menu bar will look wrong. But that's ok, since there's a good chance the user will just think they somehow accidentally got logged out of the web site and log in again.

To fix, the process of modifying the DOM needs to be made more robust. When user values are used in as DOM element identifiers, you should ensure that there can't be a conflict as there is here, for example, applying a prefix to user values like id="user_". Even better, use your own identifiers rather than user values.

This spoofing attack is easily detected when the user clicks Sign in and ends up at evil.example.com. A clever attacker could do something harder to detect, like replacing the Sign in link with a script that renders the sign in form on the current page with the form submission going to their server.