How We Protect Our Laravel Web Applications Against the OWASP Top 10 Security Risks

By Darren Chowles on Monday, 24 August 2020

Barely a week goes by without news about another data breach or large-scale attack on a popular website. The result of these attacks is devastating to the business as well as the customers involved. Businesses face loss of profits and huge fines under GDPR and other privacy laws. Customers can become targets of identity theft, or attackers can use their credentials to gain access to other services. It’s one of the reasons you should never use the same password on multiple websites.

Worst of all, many of these attacks aren’t the kind of sophisticated advanced persistent threats (APT) you hear about on the news or see in movies. They’re rudimental attacks targeting very well-known vectors like malware, social engineering, and cyber-attacks.

And even though no system is ever 100% safe, there are several approaches you can follow to make your web application more secure.

OWASP & Laravel

The Open Web Application Security Project (OWASP) is an international non-profit organisation dedicated to creating awareness about web application security. The OWASP Top 10 consists of the top critical security risks to web applications.

Laravel is a favourite development framework at ID Studio. We’ve used it for years for anything from small business websites to larger fintech and e-commerce platforms. Best of all, Laravel takes care of many of these security features out of the box. 

At ID Studio, many of our more sensitive projects have been subject to intense penetration testing, in-depth code review and GDPR compliance. We have experience in this domain and can apply that knowledge and expertise to your project.

The section below outlines the OWASP Top 10 security risks and how we protect our Laravel-based web applications against these risks.

1. Injection

SQL (Structured Query Language) is a language used to communicate with databases. Websites can be susceptible to SQL injection attacks if it doesn’t sanitise data or run queries safely. This can allow attackers to delete all of your data, obtain a copy of all your customers (including personally identifiable information, orders, messages, etc.), or insert malicious code that will attempt to install malware onto the devices of everybody visiting your website.

What we do:

• By default, we make use of Laravel best practices to ensure all queries are safe and immune to SQL injection attacks.

2. Broken Authentication

Broken authentication allows attackers to breach your system and gain entry by guessing passwords, obtaining credentials from configuration files, or stealing your session tokens.

What we do:

• We implement rate-limiting and reCAPTCHA on all login, registration and forgot password forms. This prevents brute-force attacks where a malicious actor might use automated means to try thousands of password combinations to access your account.
• We include additional security features by default: multi-factor authentication (where you use an authenticator app like Authy to generate a time-based code) as well as IP restrictions for logins.
• We never commit sensitive details into our code versioning system. This includes database logins and third-party API credentials.

3. Sensitive Data Exposure

Data breaches are becoming almost a daily occurrence. Some systems simply aren’t protecting sensitive personal, financial and health information as they should. And a breach of this is usually a catastrophic occurrence for a business.

What we do:

• The websites we develop are all served over HTTPS, whether it’s an SSL certificate supplied by the client, or using the free Let’s Encrypt service.
• All passwords are hashed using Bcrypt/Argon, which is the default function in Laravel. A hash is a fixed-size value generated from any arbitrary data, in this case, your password. Weak hashes (like those generated by MD5 and SHA1) have been exploited in the past and is something we never use.
• Any highly sensitive data is encrypted at rest using Laravel’s built-in encryption functions that use the AES-256 and AES-128 algorithms.

4. XML External Entities (XXE)

XML (Extensible Markup Language) is a text-based markup language that uses tags to identify, organise and store data. XML is used in web services, content management systems and even Microsoft’s XML-based file formats like .docx and .xlsx. Systems that process XML, especially if it’s via a third-party source, could be susceptible to an attack, allowing access to the internal network or causing a DoS (Denial of Service) attack.

What we do:

• We set the relevant configuration settings for the XML parser and ensure it’s up to date. We also advise clients where applicable when consuming XML could be a potential risk.

5. Broken Access Control

Broken access controls will allow users to access unauthorised resources. This was the case in a high-profile breach in 2011 where attackers could access the account details for almost all customers by merely changing the identifier in the browser URL once they were logged in.

What we do:

• Our Laravel CMS allows the admin to create additional admin users with very specific access permissions.
• We perform authorisation checks on all parts of the system: from the page users can access, to the actions they’re allowed to perform.

6. Security Misconfiguration

There was a time when it was almost a weekly occurrence that an unsecured AWS (Amazon Web Services) S3 bucket or Elasticsearch server was found containing millions of customer details. It became so prevalent that AWS ended up making S3 uploads private by default, with explicit warnings if you decide to make the data public.
Applications always need to be configured securely and updated frequently to reduce the risk of being exploited.

What we do:

• We keep server as well as library dependencies up to date. 
• We disable all debugging output which can expose details about your system and even access to your sensitive configuration values. Laravel has provisions that make this as simple as a configuration setting.

7. Cross-Site Scripting (XSS)

XSS exploits occur when an application allows untrusted data to be displayed without properly escaping any potentially dangerous code. This can allow attackers to hijack customer sessions (and provide the attacker with full access to their account), deface websites, or redirect your customers to malicious sites that attempt to download malware or trick them into revealing their personal details.

What we do:

• We never display user-supplied input on a website without first escaping it. Laravel’s Blade template engine allows us to display data as escaped by default using its curly bracket syntax.

8. Insecure Deserialisation

Data serialisation is the process of converting structured data into a format that can be stored and shared easily. Later, it can be converted back into its original data structure. The exploit comes in when an attacker makes changes to the serialised data. When the system unserialises this data, it can cause exploits like privilege escalation, where a user has a higher authorisation role than they did before.

What we do:

• We don’t unserialise anything from third parties.
• By default, all cookies created by Laravel are encrypted and signed. This means they’ll be invalid if somebody tampers with it.

9. Using Components with Known Vulnerabilities 

Ensuring your application is protected against things like SQL injection and XSS is only the start. If your application uses libraries with known vulnerabilities, these can be exploited regardless of the defenses you have in place.

What we do:

• We only use dependencies that are required for the specific project. Anything else is discarded. This reduces the attack surface.
• We keep all dependencies up to date and favour the LTS (Long Term Support) versions of Laravel as this provides a more extended period of bug and security fixes.
• The team subscribes to security bulletins, so we’re aware as soon as there is a vulnerability being exploited in the wild.

10. Insufficient Logging and Monitoring

Most breaches on average take more than 200 days before they’re detected. In this time, attackers can breach your system, pivot to other attacks and exfiltrate all your customer data. A crucial part of detecting breaches is by logging and monitoring all activity.

What we do: 

• Laravel comes with Monolog as standard and allows you to integrate with a third-party service like Papertrail.
• Our CMS logs all application activity: logins, forgot password requests, every action performed by members and admins on the system, etc. and provides a detailed and extensive audit trail.

Conclusion

At ID Studio, security is at the core of every website we do. If you have a project in mind, or simply want to chat, please feel free to contact us or call our London, Richmond office at 020 3908 4428.