Forging strong, common sense standards for web development can be challenging due to the massive range of in-use (let alone potential) potential software architectures coupled with rapid advances in technology and practice.
For now, OWASP has emerged as a leading standard for web security.
The Open Web Application Security Project (OWASP) is a non-profit organisation focused on improving the security of software.
OWASP has made a range of tools, including one that automatically finds security vulnerabilities in your web application, and a library that implements a variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks. They also have documentation for testing guidelines and common attack vectors.
In a nutshell, OWASP helps developers write better, more secure code and gives consumers a better understanding of what’s possible (both in terms of attack and mitigation).
Many common attacks break down into 13 categories:
- SQL Injection (SQLi)
- Cross Site Scripting (XSS)
- Local File Inclusion (LFI)
- Remote File Inclusion (RFI)
- Remote Code Execution (RCE)
- PHP Code Injection
- HTTP Protocol Violations
- Session Fixation
- Scanner Detection
- Metadata/Error Leakages
- Project Honey Pot Blacklist
- GeoIP Country Blocking
Wow! That’s a lot, but what are the top risks?
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorisation.
An example of poor security is when an SQL statement, such as...
txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;
...can be inserted into an input field intended for comments on a blog.
Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently.
As the name suggests, the key here is not authorisation, but authentication.
Watch this video for a better understanding of the difference here.
In a nutshell, the issue is not the application letting the wrong people access resources, but the application letting people assume alternate, more privileged identities, and consequently resource access.
Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
Ok, so there’s a lot of potential attack vectors… but how are we doing?