And Yet Another Weekend Post! (YAWP)
Securing computer applications and software is one of the most significant stages of planning for development. The level of usage is what determines success, and it reflects the number of active users in the app.
What is OWASP?
The Open Web Application Security Project (OWASP), is an international non-profit organization dedicated to web application security. One of OWASP’s core principles is that all of their materials be freely available and easily accessible on their website, making it possible for anyone to improve their own web application security.
The group supporting the project is comprised of a range of web security experts from all around the world. They share their knowledge and experience about existing vulnerabilities, threats, attacks and countermeasures.
The idea is to gather the most important information that enables you to access security risks and ways to combat them effectively. It’s like betting experts, trying to condensate the knowledge they have about football teams’ performances. That way, they can predict who will flop and who will thrive and be potentially NFL MVP. The OWASP works the same way, to ensure the best practices for securing your software.
However, as every project, OWASP also has its own vulnerabilities. This list also shows its risks, impacts and countermeasures. Updated every three or four years, the last release was this year.
OWASP Top 10 Vulnerabilities
A code injection happens when a hacker sends invalid data to the web application with the intention of doing something different than what the application was designed/programmed to do.
The attacker sends invalid and untrusted data to the application as part of a command or query. The attacker has the malicious intention to trick the application into executing unintended behavior to collect data or create damage.
A couple of the more common injections are:
How to prevent Injection-Attacks?
Keep data separate from queries. This is the main key to prevention.
Create a “white list” for server-side input validation.
Use LIMIT and other SQL controls to prevent mass disclosure in case of an attack.
Use safe APIs to eliminate the use of an interpreter. This lowers the risk of SQL injections.
A broken authentication vulnerability could allow an attacker to use manual and / or automatic media to try to take control over any account they want on a system – or even worse – to gain full control over the system. Websites with broken authentication vulnerabilities are very common on the web. Broken authentication usually refers to logical issues that occur in the application’s authentication mechanism, such as incorrect session management prone to username enumeration.
One of the most simplest ways to prevent such an attack is: not making the administrators login page publicly accessible to all sites or IP addresses.
How to prevent broken authentication attacks?
Do not deploy any default credentials
Store passwords using a modern one-way hash function
Implement multi-factor authentication to prevent credential stuffing, brute force, and stolen credential attacks.
Log authentication failures and alert administrators when attacks are detected.
Limit the attempts for authenticating
Secure your password storage
Implement weak password checks against a list of the top 10000 worst passwords.
Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes
Exposure to sensitive data
Exposure to sensitive data is one of the most common vulnerabilities. It involves compromising data that should have been actually protected, such as credit card numbers, passwords or even health cards. It is vital for any organization to understand the importance of protecting user information and privacy. All companies must comply with their local privacy laws.
How to prevent such an Data Exposure attack?
Password hashing storages
Key generation process
Discard data as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.
Make sure to encrypt all sensitive data at rest.
Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters.
Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
Disable caching for responses that contain sensitive data.
Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
Classify data processed, stored, or transmitted by an application.
Apply controls according to the classification.
Don’t store sensitive data unnecessarily
Ensure that stored passwords have a strong adaptive algorithm such as bcrypt, Argon2, scrypt or PBKDF2.
Verify independently the effectiveness of your settings
XML External Entities (XXE)
An XML attack happens when an application that parsers XML input is under attack.Most XML parsers are vulnerable to XXE attacks by default. Developers should be carefull specially about mitigation steps of such an attack. This type of attack may lead to the disclosure of sensitive data, DOS attack, server-side request forgery, and so on.
How to prevent such an attack?
Most XML parsers are vulnerable to XXE attacks. This is why it is so important to train the developers, so they can learn to identify and mitigate risks.
Patch or upgrade the latest XML processors and libraries in use by the application or by the operating system. Use dependency checkers to manage the risk from necessary libraries and components for any integrations.
Verify that xml/xls file upload functionality validates the XML using XSD validation or something similar.
The safest way to prevent XXE is always to disable DTDs (External Entities) completely depending on the parser. The configuration method should be something like the following:
As a bonus, disabling DTDs also makes the parser secure against a denial of service attack. If you want to learn more about prevention guidance for a specific language and commonly used XML parsers, I recommend taking a look at the OWASP XML cheat sheet.
Implementing positive or “whitelisting”: input validation, sanitation, and filtering can help to prevent hostile data within XML documents, headers or nodes.