What security issues need to be addressed when working with Google App Engine?

views:

answers:

+4 Q:

What security issues need to be addressed when working with Google App Engine?

I've been considering using Google App Engine for a few hobby projects. While they won't be handling any sensitive data, I'd still like to make them relatively secure for a number of reasons, like learning about security, legal, etc.

What security issues need to be addressed when working with Google App Engine?

Are they the same issues that other applications - like applications written in other languages or hosted in other ways - are faced with?

Edit: I did some searching it looks like I need to sanitize input for XSS and Injection. What are other things to consider?

In general there are the same issues. In addition google "knows" your code and can in theory monitor anything what the code is doing. Therefore it is very difficult if you want to prevent them from reading your data. But i don't believe they have time and resources to monitor your code and data that close.

kasten 2010-10-06 09:18:41

I'm not really concerned about Google 'knowing' my code or reading my data, if thats what my question seemed to communicate then I apologize. I'm more interested in security issues that can leave my application open to exploitation to things like XSS and SQL Injection, in particular security vulnerabilities that are unique to Google App Engine.Do you have any tips on how I can modify my question(s) to better communicate this? Thanks for the answer regardless.

Ocimus 2010-10-06 09:27:34

I wanted to say that there are no special security risks for a google apps engine which you can counteract. Google just hosts your code as any other Hoster would do. If they have a hole in their system you can't do anything about it.

kasten 2010-10-06 09:38:11

Alright thanks, I understand now.

Ocimus 2010-10-06 10:02:07

+4 A:

“Sanitising” input is not the way to avoid query-injection and markup-injection problems. Using the correct form of escaping at the output stage is... or, even better, using a higher-level tool that deals with it for you.

So for preventing query-injection against GQL, use the parameter-binding interface of GqlQuery. For preventing markup-injection against HTML (leading to XSS), use the HTML-escaping feature of whatever templating language you're using. For example, for Django templates, |escape... or, better, {% autoescape on %} so you don't accidentally miss one.

bobince 2010-10-06 09:39:38

Thanks for the great information, this is the sort of thing I've been searching for. Are there other vulnerabilities that need to be consider?

Ocimus 2010-10-06 09:58:16

Well, sure, depends what you're doing, doesn't it? If you're letting people submit links, you'd better check the URL is a known-good scheme like `http` and not `javascript`... if you allow file uploads you'd better save them under a safe name and not a user-submitted one... don't serve user-submitted files from your main hostname... don't use user-submitted data in a `system` command or `eval`... etc etc

bobince 2010-10-06 11:43:40

In practice, GQL injection attacks are nearly impossible even if your code is fairly horrible, since the attacker would be limited to adding additional criteria to a SELECT statement. That's not to say you shouldn't use parameter binding, but it's not as serious an issue as with SQL.

Wooble 2010-10-06 12:51:18

ansaurus

tags:

views:

answers:

What security issues need to be addressed when working with Google App Engine?

related questions