OWASP or oh no: web security standards
by Mitchell Tweedie, Dec 14, 2018
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.
What is OWASP?
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).
What do the OWASP standards include?
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?
OWASP’s top 3 security risks for cloud-based applications
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.
Sensitive data exposure
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.
Are apps meeting this standards?
Ok, so there’s a lot of potential attack vectors… but how are we doing?
Over 80% mobile apps have crypto flaws and 4 of 5 tested web apps fail OWASP security standards. This is why picking the right SaaS vendor is critical, it’s so easy to get wrong!