The OWASP Top 10
A2 Broken Authentication: Permits a hacker to log in, masquerading as a legitimate user or allows them to take over another person’s session. Mitigation includes:
​
-
Offering two factor authentication. For example, you need a pin sent to a mobile phone as well as a password to log in.
-
Encrypting all communications (or turning them into gobbledegook) with TLS 1.2 or 1.3 so they cannot be read by a malicious 3rd party.
-
Configuring websites to enforce session time outs if the visitor is no longer using the site. This stops others using your connection when you’re done!
-
Use industry standard authentication systems: SAML, OpenID, Kerberos which help protect user credentials through secure login.​
​​
A3 Sensitive Data Exposure: Any sensitive data must remain confidential. Encourage:
-
Employees to use an up-to-date browser.
-
Configure servers to choose the best encryption methods for communicating with end users. When a person wishes to interact with your website, your server will decide what encryption techniques will be used from a list supplied by the end user’s computer. Old encryption methods can be broken and will expose sensitive data. It is good practice, therefore, to configure servers to only use new, more powerful encryption techniques.
-
Categorise company data based on sensitivity so that the appropriate security controls can be applied and employees understand the risk of exposure when handling it.
​​
A4 Insecure References: A URL link: www.emsou.com/cyber&fraud/finance/robertsmith can expose information about how internal systems and apps work, giving hackers access to them without going through proper authorisation procedures.
-
Test applications for insecure references.
-
Ensure every user must go through authentication (i.e. they must login to prove who they are) and then grant permissions based on least privilege (i.e. you can only do stuff that you absolutely need to).
​
A5 Broken Access Control: Is about checking the permissions a user has when they login. An online medical system should not let a student nurse change a patient’s medication, but a doctor will need these permissions. You should make sure that:
-
The site checks the user is authorised to access each and every web function.
-
Systems are configured to deny access by default. For example, the rules don’t say whether the nurse is able to book an appointment so we default to ‘computer says no’.
-
Permissions granted to different user groups are frequently audited. This is because people regularly come and go. They pick up new responsibilities and relinquish others. Business models also change and with it, ‘who has access to what’. Monitoring permissions, therefore, is a critical part of preventing unauthorised access and unauthorised changes to systems and data.
​
A6 Security Misconfigurations: When web apps and systems are not securely configured or maintained, problems ensue. For example, leaving a default administrators account on the server, is one step away from a data breach. To mitigate such problems, you should:
-
Use vendor guidelines when hardening hardware and software.
-
Have systems or processes in place to ensure baseline compliance and the prevention of unauthorised changes (known widely as ‘change management’).
A7 Cross Site Scripting (XSS): A hacker will plant malicious code on a website which runs on the browser of a site visitor. The attacker can then hijack the connection, steal credentials and data and install malware. Mitigation involves:
-
Turning code into text when a web page is submitted (‘escaping’).
-
Limiting the amount of text that can be entered on a site (called a ‘field length’ check) and using drop downs where possible to reduce input. These ‘validation’ techniques prevent the end user entering malicious code.
-
It is also possible to add a security policy in the web page that prevents the running of ‘foreign’ scripts.
​A8 Insecure Deserialization: When files are sent over the internet, they are usually translated into a format that can be moved more easily. Once the file reaches its destination, it is translated back into its original form. In one recent example, an attacker corrupted this process by inserting crypto mining software and earned a hefty $3 million (and a prison sentence) in the process. It is advisable to:
-
Encrypt the translated data which makes tampering harder.
-
Use a Web Application Firewall to check incoming data packages for suspicious payloads.
-
Ensure that the system which translates data cannot run these dangerous payloads.
-
Translate data only if it is ‘digitally signed’. This verifies that the package comes from a trusted source and has not been tampered with.
​
A9 Using Components with Known Vulnerabilities: Web developers sometime use software or code for which there are known security flaws . . . Mmm . . . not helpful! Your best bet is to
-
Perform periodic scans (there are plenty of vulnerability scanners out there) and carry out audits to identify these security issues.
-
Develop a program to assess and implement patches and software updates to fix these weaknesses.
​
A10 Insufficient Logging & Monitoring: When web systems fail to track user activity, malicious actions go unnoticed. Some companies will log these activities but then fail to protect these logs from tampering or fail to periodically review them. Always
-
Make sure that systems securely track who, when, where and what.
-
Store these logs in a ‘bastion host’. In other words – store them on a system that is heavily locked down and benefits from encryption.
The World Wide Web is a sprawling network of computers with billions of websites advertising goods and services. However, websites with flawed security bring only financial loss and reputational harm.
​
The OWASP Top 10 identifies the ten most common threats to websites. Breaking the project down, we have:
​
A1 Injection: A hacker will enter code into the website in order to extract information from the database that sits behind it - including customer information or information about users sat on the internal network. Mitigation includes:
-
Turning code into text when a web page is submitted. This prevents harmful scripts from running.
-
Using a Web Application Firewall (WAF) or a Database Activity Monitor (DAM) which will detect and prevent malicious activity on your website.
-
Using parametrised queries. About 90% of the interaction between your web page and database is done by running a query. For example, a query might; lookup a user’s login credentials, check if an item is in stock, or make a booking. That being said, it is possible to write these queries beforehand and only allow these ‘sanctioned’ commands the ability to run. Some form of user input will still be needed - for example, the date and time of the booking or the username and password for the log in - but these ‘parameters’ cannot alter the form or function of the query.