Hacksplaining is a newly established web site that encourages hacking in order to learn and protect against it. Everyone in the web development business knows achieving a secure web site, to the degree that is possible, is difficult. It's a task of utmost concern that must be integrated into the building stages of the site, not applied afterwards.
Security wise, there's just too much for the web developer to follow, having to cope with terms and acronyms like SQL Injection, XSS and CSRF etc that tend to confuse rather than help to maintain focus.
The web might be already filled with lots of satisfactory documentation on web vulnerabilities. However these are chaotically distributed, primarily text-based and require lots of effort and digging through to comprehend.
hacksplaining.com is yet another attempt to educate web developers on security issues, but adopts an alternative approach; learn to protect yourself through hacking yourself.Its visually appealing content and an the interactive way of involving the user in the learning process, offer a solid answer to the hindrances that today's developer encounter in their attempts at achieving security consciousness.
It combines animated graphics to showcase the vulnerability while at the same time, through interactive examples, prompts and instructs the student to hack the test site like a pro hacker would do. The notion here is that the best way to understand and prevent, is by filling the enemy's, or hacker's in this case, shoes.
The vulnerabilities have meta data attached;that is they are classified by severity of their Prevalence, Exploitability and Impact (if exploited). For example, SQL Injection is classified as a vulnerability that is occasionally performed but easily exploited and with devastating impact upon successful exploitation.
The range of vulnerabilities showcased span from SQL Injection to XSS and its subdivisions (Persistent, DOM based, Reflected), CSRF, Unencrypted Communications, etc, hence providing a complete view of the things that need to be known.
But that's not all. After you complete each example, thus having experienced the ways of both discovering and exploiting the vulnerability, you are then presented with text based guidance on the preventative measures that should be employed for mitigating that risk. The guides are backed with code examples in popular languages such as Ruby, PHP, C# etc.
For example, after completing the SQL Injection example, we are advised to:
- use Parameterized Statements, as
Programming languages talk to SQL databases using database drivers. A driver allows an application to construct and run SQL statements against a database, extracting and manipulating data as needed. Parameterized statements make sure that the parameters (i.e. inputs) passed into SQL statements are treated in a safe manner.
- be cautious that
Using an ORM does not automatically make you immune to SQL injection, however" or "As a general rule of thumb: if find yourself writing SQL statements by concatenating strings, think very carefully about what you are doing
- Escaping Inputs, when
you are unable to use parameterized statements or a library that writes SQL for you, the next best approach is to ensure proper escaping of special string characters in input parameters
- Sanitizing Inputs, as
Sanitizing inputs is good practice for all applications.
Developers should always make an effort to reject inputs that look suspicious out of hand, while taking care not to accidentally punish legitimate users
- with extra considerations
Principle of Least Privilege, Password Hashing, and Third Party Authentication
The code samples (in Python in this case) that follow illustrate good and bad practices:
# SQL and parameter is sent off separately to the
# database driver.
cursor.execute("select user_id, user_name
from users where email = ?", email) for row in cursor.fetchall(): print row.user_id, row.user_name
# String concatenation is vulnerable.
cursor.execute("select user_id, user_name from
users where email = '%s'" % email) for row in cursor.fetchall(): print row.user_id, row.user_name
The first four exercises are freely available, but the rest require registration, although there is no cost to the user since singing up is free. The intention for the existing material is for it to remain free to everyone, indefinitely, and to charge companies to track their in-house staff as they go through the training.Premium customers will also benefit from extra and more rigorous testing