Tu Na Thakega Kabhi,
Tu Na Thamega Kabhi,
Tu Na Mudega Kabhi,
Kar Shapath, Kar Shapath, Kar Shapath,
Agnipath, Agneepath, Agnipath!

Yeh Mahan Drishya Hai,
Chal Raha Manushya Hai,
Asru, Swed, Rakt Se
Lathpath, Lathpath, Lathpath,
Agnipath, Agnipath, Agnipath!

Kuch Zakhm Lage the Chehre Par,
Kuch Andar Se Hum Toot Gaye.

Kuch Hum the Tabiyat Ke Saade,
Kuch Log Begane Loot Gaye.

Kuch Apno Ne Badnaam Kiya,
Kuch Ban Afsane Jhoot Gaye.

Kuch Apni Shikasta Nao Thi,
Kuch Humse Kinaare Choot Gaye.

Over the last 4 years I’ve found that there is a BIG downside to using frameworks like Django:
The thing is, we are a reasonable/honest bunch of folks providing development services. Our clients expect us to to charge by the hour.
There is no way Django development allows us to make enough money… the God-damn apps get built too quickly for too little.

Its about time we moved to J2EE development …

Integrity of your data. I should not be able to change it.
Confidentiality: can I access what I should not be able to access?
Availability: can I break your website?

A well-known bad case is DigiNotar. Malware on most of their computers, including the most secure once. Their digital certificates were compromised and the company went bankrupt in three weeks time.

One thing that we have to take care of regarding Django: cookies. Cookies are stored in your browser and are linked to a website. All requests to that website get the cookies in every request. In Django, your session ID is stored in your cookie. If you get hold of the session ID, you get hold of the user’s session. Django stores the actual session’s data in the database, so the actual data is safe.

CSRF: cross site request forging. Tricking the browser into posting requests to other websites. http://your-router/set_password?pwd=hamster . Django protects you by adding a secred csrf_token to every POST form and checking for it. So you’re safe.

XSS injection. Cross site scripting. Happens when you don’t filter/escape user submitted content. So you could send a<script type=”text/javascript”>// <![CDATA[
tag with a script that for instance steals every cookie on your server for stealing session IDs. Common is tricking a single user into running the script. A more powerful, but rarer, way is to get a script on some website and trick everyone visiting the site…

Django is mostly safe as it escapes template tag output by default. There is a rare vulnerability if you don’t put double quotes around html attributes. Everything after a space in var in

ends up as a separate attibute…

Cookie security is pretty good in Django. 1.4 sets SESSION_COOKIE_HTTPONLY to true. You ought to do this always. And if you always use https, set CSRF_COOKIE_SECURE and SESSION_COOKIE_SECURE to true.

And… don’t trust in a regex that filters dirty tags out of your user-submitted code. There are SO many tricks and ways to circumvent any regex. Use markdown or something like that.

SQL injection is common, but Django has no know exploits. It is rock solid. But there are other ways. For instance LDAP injection. Don’t put an unfiltered username into your LDAP query as you can hack the query. Or direct user input into filenames. And what about shell injection? some_filename.txt;rm -rf… Shell calls are always very risky, but Python’s subprocess() helps a lot.

There’s a difference between validation and escaping. Validation is done as early as possible. Escaping is done as late as possible. Both serve a different purpose. As always: whitelisting is better than blacklisting.

A new option is clickjacking that overlays a transparent website over another one, stealing your form fields and clicks. It works with iframes. Django 1.4 has a new X_FRAME_OPTIONS=’DENY’ that works with newer browsers.

And… Don’t trust browsers. If you disable something in javascript, a user can work around it, for instance. The speaker could always book rooms in school before anyone else could as the only-two-weeks-in-advance limitation was implemented in javascript, not in the backend…

Regarding tests: check login-protected pages as anonymous first. Check actions for the admin user first as anonymous, then as a regular user. Check it.

And if you run some test site that’s (temporarily) on an external IP address, you can be sure someone finds it. So watch out.

If you run backups, do you also run restores? Do you keep backups with a different provider? Once a provider was hacked and its servers were wiped. Including their backups. All customer data lost.

Django: don’t ever run it in DEBUG mode in production. It gives away way too much information. Another tip: name the admin url something different than /admin. it is a dead give-away that it is a Django website.

Watch out for other apps on the same server. Your Django server can be compromised by running some faulty-configured PHP code on the same server.

Always restrict database access per app.

Summary. Django helps out with CSRF, SQL injection and XSS; you need to take care of all other injection attacs (LDAP, filesystem, etc). Use the build-in Django security features. And never trust what the browser sends. And secure the web server itself as well. Make backups.

Author: Reinout van Rees
Talk at the 2012-01-18 Dutch Django meeting

Also check out  django-secure, it’s a Django app that helps you remember to do the stupid little things to improve your Django
site’s security: https://github.com/carljm/django-secure/

FurnitureDirectory.com
FastBridge.com
HyperPoint.com
PrivateCorner.com
vMoney.com
WebChimp.com
WhiteCurrant.com
SmartSaaS.com
TrendManager.com
BrainMirror.com
FireMonk.com
DoubleShock.com
BlueEmerald.com
FrozenEgg.com
NetSpear.com
TaskHorse.com
ZeroHazard.com

Personally, I think its time for some REAL change in America; peace, tolerance, innovation, equal opportunities, and some tough decisions to fix the economy. The only person who has the ability and resolve to do this seems to be Ron Paul. The other candidates promise more of the same.

I pray that its Ron Paul in 2012 … he’s America’s last hope.
Too bad that my support/vote doesn’t count … I’m NOT American!

Some notable projects using the Play framework:

http://typesafe.com

http://www.guardian.co.uk

http://gendi.fr

http://www.seine-et-marne.fr

http://www.sparkmuse.com

The Play framework makes it easier to build Web applications with Java and Scala. PLAY is a clean alternative to bloated Enterprise Java stacks. It focuses on developer productivity and targets RESTful architectures. Great for agile software development!

Although we are Django fanboys; I have to concede that PLAY has some incredible advantages in building scalable web apps.
My biggest grouse with Java platforms is repeated and tedious compile-package-deploy cycles. However, The PLAY framework compiles your Java sources directly and hot-reloads them into the JVM without the need to restart the server. You can then edit, reload and see your modifications instantly!

At DoubleSpring, we are in the market for web app development services in the PLAY framework. If you are interested in discussing your project or idea, get in touch with us.