The cost of cybercrime continues to increase each year. In a single day, there are about 780,000 data records are lost due to security breaches, 33,000 new phishing messages, and 4,000 ransomware attacks globally. Analysts expect the total cost of cybercrime to reach $2 trillion in 2019, which is a threefold increase compared to 2015.
Many of the attacks perpetrated by cybercriminals are performed using software vulnerabilities. Software vulnerabilities are often programming mistakes or oversights that leave web applications, web servers, or websites exposed. It is up to the software programmers to create applications with a high standard of security to prevent these attacks from occurring.
Although securing a website or network resource can be a difficult task, it is made easier thanks to the work done by The Open Web Application Security Project (OWASP). OWASP provides a comprehensive list of security design principles that programmers should adhere to. Following these principles will ensure that your application is secure and dramatically reduces the risk of a successful cyber attack.
What is OWASP?
OWASP is an online community that produces free tools, documentation, articles, and technologies to help people secure their websites, web applications, and network resources. It was founded by Mark Curphey, an experienced information security specialist, in 2001. Their primary focus is on web security, application security, and vulnerability assessment.
What are the OWASP Security Design Principles?
The OWASP Security Design Principles have been created to help developers build highly secure web applications. The OWASP security design principles are as follows:
Before developing any security strategies, it is essential to identify and classify the data that the application will handle. OWASP suggests that programmers create security controls that are appropriate for the value of the data being managed. For example, an application processing financial information must have much tighter restrictions than a blog or web forum.
Programmers should design controls that prevent misuse of the application by different types of malicious parties, including (from most to least dangerous):
- Disgruntled staff members and programmers
- Drive-by attacks that release viruses or Trojan attacks onto the system
- Motivated cybercriminals
- Criminal organisations with malicious intent
- Script kiddies
The most dangerous type of attacks that developers must safeguard against are from disgruntled staff members and programmers. That’s because they usually have a high level of access to sensitive systems. Programmers can use OWASP principles techniques to safeguard against these types of attacks.
Core pillars of information security
OWASP recommends that all security controls should be designed with the core pillars of information security in mind:
- Confidentiality – only allow access to data for which the user is permitted
- Integrity – ensure data is not tampered or altered by unauthorised users
- Availability – ensure systems and data are available to authorised users when they need it
OWASP recommends that every application has application security measures designed to cover all kinds of risks, ranging from typical usage risks (accidental data erasure) through to extreme attacks (brute force attacks, injection attacks etc.).
They recommend that developers should consider each feature on the application they are designing and ask the following questions:
- Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?
- If I were evil, how would I abuse this feature?
- Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature?
By “thinking evil” developers can identify the ways that cybercriminals and malicious individuals might seek to attack a web application. OWASP suggests that developers also following the STRIDE / DREAD threat risk modelling technique used by many corporations. STRIDE helps programmers identify threats and DREAD allows programmers rate threats. You can read more about STRIDE / DREAD here.
These principles are taken from the OWASP Development Guide and comply with the security principles outlined in Michael Howard and David LeBlanc’s book Writing Secure Code. They include:
1. Minimise attack surface area
Every time a programmer adds a feature to their application, they are increasing the risk of a security vulnerability. The principle of minimising attack surface area restricts the functions that users are allowed to access, to reduce potential vulnerabilities.
For example, you might code a search feature into an application. That search feature is potentially vulnerable to file inclusion attacks and SQL injection attacks. The developer could limit access to the search function, so only registered users could use it — reducing the attack surface and the risk of a successful attack.
2. Establish secure defaults
This principle states that the application must be secure by default. That means a new user must take steps to obtain higher privileges and remove additional security measures (if allowed). Establishing safe defaults means there should be strong security rules for how user registrations are handled, how often passwords must be updated, how complex passwords should be and so on. Application users may be able to turn off some of these features, but they should be set to a high-security level by default.
3. The principle of Least privilege
The Principle of Least Privilege (POLP) states that a user should have the minimum set of privileges required to perform a specific task. The POLP can be applied to all aspects of a web application, including user rights and resource access. For example, a user who is signed up to a blog application as an “author” should not have administrative privileges that allow them to add or remove users. They should only be allowed to post articles to the application.
4. The principle of Defence in depth
The principle of defence in depth states that multiple security controls that approach risks in different ways is the best option for securing an application. So, instead of having one security control for user access, you would have multiple layers of validation, additional security auditing tools, and logging tools. For example, instead of letting a user login with just a username and password, you would use an IP check, a Captcha system, logging of their login attempts, brute force detection and so on.
5. Fail securely
There are many reasons why a web application would fail to process a transaction. Perhaps a database connection failed, or the data inputted from a user was incorrect. This principle states that applications should fail in a secure way. Failure should not give the user additional privileges, and it should not show the user sensitive information like database queries or logs.
6. Don’t trust services
Many web applications use third-party services for accessing additional functionality or obtaining additional data. This principle states that you should never trust these services from a security perspective. That means the application should always check the validity of data that third-party services send and not give those services high-level permissions within the app.
7. Separation of duties
Separation of duties can be used to prevent individuals from acting fraudulently. For example, a user of an eCommerce website should not be promoted to also be an administrator as they will be able to alter orders and give themselves products. The reverse is also true — an administrator should have the ability to do things that customers do, like order items from the front end of the website.
8. Avoid security by obscurity
This OWASP principle states that security by obscurity should never be relied upon. If your application requires its administration URL to be hidden so it can remain secure, then it is not secure at all. There should be sufficient security controls in place to keep your application safe without hiding core functionality or source code.
9. Keep security simple
Developers should avoid the use of very sophisticated architecture when developing security controls for their applications. Having mechanisms that are very complex can increase the risk of errors.
10. Fix security issues correctly
If a security issue has been identified in an application, developers should determine the root cause of the problem. They should then repair it and test the repairs thoroughly. If the application uses design patterns, it is likely that the error may be present in multiple systems. Programmers should be careful to identify all affected systems.
For more web security articles, please subscribe to our website.