piątek, 7 grudnia 2012

Book review: Innocent code

Foreword:
As I was exploring, security related research papers, and books, I came to one conclusion: Who will ever have time to read this all and apply it?? And the answer is simple nobody. Especially not peoples that should... software developers. Information security is treated like higher level knowledge, you either are a security specialist or you don't know anything. And this is a big big problem. Today's software developers don't have time to write a decent code, and test it  thoroughly, not thinking even of security education. Today anybody can be a software developer. And many people write apps without any prior education. And it poses a problem, because even if a software developer has a Masters degree in programming, security education is at insufficient level at best, often there is none at all. That is the problem. Secure software development is portrayed as something done only by big corporations and only for security critical software, and it's somewhat true. Deploying a Secure Software Development Life Cycle requires a lot of time, a lot of money and a lot of sharp people. Not every company can afford that. So are we doomed to ubiquitous security vulnerabilities, and insecure applications ? The answer is NO!

Innocent Code - To the rescue!
In short a GREAT book. This is the book that tackles the most profound security issues in web applications. Shows you what malicious people can do with your precious application. Without any special tools, just by knowing your programming patterns. It is pretty concise, presents you a set of rules, that when followed, will provide a very good security foundation for your application. This book SHOULD be read by every software developer. It's not too detailed it's just what it should. It can be easily understood by developer who has nothing or not much common with security. This book is not only good book, for developers working with SSDLC, but for day to day programmers, which employers don't have money nor the resources to introduce SSDLC. By reading this book and applying presented rules, withot SSDLC you will significantly improve security of your web application!. And It does not take too much time. And can save you a loot of stress.

Where to go:
If you want more:
Enterprise Java Security - Building secure J2EE Applications
Security engineering - A guide to building dependable distributed systems 
Hacking exposed Web Applications
Exploiting Software - How to break code
Gray hat hacking
Writing secure software
And https://buildsecurityin.us-cert.gov

 


 

czwartek, 6 grudnia 2012

Secure password storage

Recently I've seen a post of someone being really supprised, that his site was hacked. He was aware that his site is prone to SQL-Injection, but he couldn't understand how it could lead to a successful login.
His passwords was SHA-256 hashed. Was it possible for attacker to reverse actual password ? Unlikely... all the needed to do is to write a union select:

select username, password from users where username = '-1'
union select 'admin','8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918' from dual;

password is hashed 'admin' string, and he was able to trick authentication
checking logic, by providing 'admin' in password string. Simple right ? So I started wondering is there a way to hash passwords in a way that would withstand such attack (of course if your app is prone to SQL-Injection you fix IT! not leave it and wish for the best). And I there is a way.

The algorithm for hash creation could be something like:
  1. Define a cryptographically secure hash function like: sha256
  2. Define web application global secure random password, lets denote it: key
  3. Get username credentials (username, password).
  4. Create a salt := sha256(username + secure_random)
  5. Calculate hash:= sha256(salt + password + key)
  6. Store salt+hash in database.

And now the checking algorithm:

  1. Lookup (salt+hash) tuple for given username.
  2. Calculate provided_hash:= sha256(salt + provided_password + key)
  3.  Compare provided_hash with hash
  4. If they match your user can be authenticated
Why is this scheme more secure? It's simple, even if attacker can extract stored salt, or if he knows the length of stored salt he can try to fake it. He will not have access to your secret key, thus he won't be able to calculate a valid hash.

P.S.: SHA can be replaced by some KDF function like PBKDF2 or scrypt.

sobota, 3 grudnia 2011

Bad webapp coding

Hi all, I wanted to show you how to never ever ever ever never ever write web app that allows for custom js or css:


I know that it's obvious but as I say sometimes the most obvious things are the ones that got missed. Solution? Don't do that but if you have to don't be so generic include file let's say custom.js from base directory and let client put there everything he want's the same thing with css.

Think, predict, secure, regards Fatfredyy

wtorek, 29 listopada 2011

J2EE - third party libraries potential insecurity

Introduction
   In these days we (software developers) relay on third party libraries, to help us do our work faster. This is a potential way for a malicious code to sneak in to our most secure application/s ;). Imagine a library that parses JSON/CSV/XML, or does some other useful things for us. This library is fairly simple, but contains a piece of code that will find all context variables that will contain url/and passwords for other systems, or it can silently connect to our db and start downloading our data. There is always issue of how to export but we have HTTP/MAIL/DNS/ICMP/file. Given how many open source projects are out there, and how much of them is in use,  it is a big field to mess with. 

Why should it concern me ?
  Because nobody (or almost nobody) ever views the sources for library that's being used. Why ? - Time. Nobody has enough time to properly finish their project, not even thinking about viewing sources of libraries we use on daily basis. None sane manager will allow his developers to spend their time on analyzing thousands of lines of code. That is why this all could slip unnoticed. 


What can we do?
   As you probably already know there is not much that we can do about it, and we wont eliminate every threat. But what we can do:
  1. We can sign jars - but it doesn't do us any good because we already trust our source. 
  2. We can review source code - but it is extremely time consuming, and sources doesn't have to match compiled classes so we should build jar ourselves. 
  3. We can attach a security manager policy file - and I think this is a most cost effective countermeasure we can do.
So more about policy. This file should be provided by library developer and contain informations on what this lib should have access to, i.e. file or net. It should be obvious that library that parses JSON should not access network or HDD. If we have such file attached to library we can analyze it in much shorter time and be able to tell, if this lib is safe. Of course if we won't use Security Manager or our brain or view security policy file there is only this much work that can lead us nowhere. The idea is that we can present this idea to open source developers/foundations to encourage more secure software development process. 


As always please rate and comment.


Think and predict, regards Fatfredyy.