Top 10 OWASP vulnerabilities
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
Injection
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:
SQL
LDAP
Expression Language (EL) or OGNL injection
OS command
ORM
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.
Broken Authentication
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?
Key management
Protocol usage
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.
Broken Access Control
Happens when there are internal references to objects (such as a folder,file or registry) without access control that can be manipulated for unwanted access.
How to prevent a Broken Access attack?
Follow the Principle of Least Privilege, where the user should only have access to the minimum privileges that are necessary to perform actions. Nothing more than what their role is intended to do.
Disable web server directory listing, and ensure file metadata such as git is not present within web roots.
Monitoring and logging are extremely important when access control fails the incident should be logged and send an alert to admins.
Use Rate limiting API and controller access to minimize the harm from automated attack tooling.
It is recommended for developers and QA engineers to include functional access control unit and integration tests.
Implement access control mechanisms once and re-use them throughout the application.
Model access controls should enforce record ownership, rather than accepting that the user can create, read, update or delete any record. For example, a user should only be able to modify or delete data that is their own. If I log in to an application, I should only be allowed to modify mydata.
Domain access controls are unique to each application, but business limit requirements should be enforced by domain models.
Security Errors
When junior admin just got hired with a scriptkiddy background! 😊 Users may be able to perform unwanted actions for lack of correct security configuration. Automatic and periodic scans are useful for detecting configuration errors, missing updates, default account usage, etc. It is important to have a fast and effective process for deploying properly protected environments and keeping them up to date, with an architecture that offers secure separation of components. How to prevent such an attack?
A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down.
Development, QA, and production environments should all be configured identically (with different credentials used in each environment). The process can be automated to minimize the effort required to set up a new secure environment.
Establish a prioritizing system to deploy all updates and patches in a timely manner to each deployed environment. This process needs to include all frameworks, dependencies, components, and libraries (free of vulnerabilities).
Promote a strong application architecture that provides effective secure separation between components, with segmentation, containerization, or cloud security groups.
An automated process to verify the effectiveness of the configurations and settings in all environments.
Remove or do not install any unnecessary features, components, documentation, and samples.
Remove unused dependencies and frameworks.
Cross Site Scripting (XSS)
Exploitation of the XSS vulnerability makes an attacker able to insert malicious scripts into pages that would be trusted and use them to hijack users and administrators. Although the attack’s structure of operation is kinda different, the spread is similar, a website link that is being attacked is prepared by the cybercriminal to perform malicious functions and is sent to the victims.
Always be aware when opening incoming links, even if the sender is a close acquaintance, before clicking make sure the link has no malicious content, such as having symbols including in the address.
How to prevent XSS attacks?
Use safer frameworks that automatically escape for XSS by design, such as in Ruby 3.0 or React JS.
Apply context-sensitive encoding when modifying the browser document on the client-side to act against DOM XSS. When this cannot be avoided, similar context-sensitive escaping techniques can be applied to browser APIs as described in the OWASP DOM based XSS Prevention cheat sheet.
Enable a Content Security Policy (CSP), which is a defensive, in-depth mitigating control against XSS. This assumes that no other vulnerabilities exist that would allow placing malicious code through local files including path traversal overwrites, or vulnerable libraries in permitted sources, such as content delivery network or local libraries.
Escape untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) to resolve Reflected and Stored XSS vulnerabilities. The OWASP XSS Prevention Cheat Sheet has details on the required data escaping techniques.
Insecure Deserialization
Applications distributed with public listeners or applications which are dependant on maintaining client state are likely to allow serialized data tampering.
Do not accept serialized objects from untrusted sources or serialization that only allows primitive data types. If this is not possible, implement integrity checks or encryption of serialized objects to prevent hostile object creation or data tampering.
Another point is to isolate code that deserializes, such as those running in very low privilege environments or temporary containers. It is important to log de-serialization exceptions and failures. Restrict or monitor incoming and outgoing connectivity from containers or servers that de-serialize and, set alerts if a user is constantly de-serializing. Using components with known vulnerabilities
How to prevent such an attack?
Implement integrity checks or encryption of the serialized objects to prevent hostile object creation or data tampering
Log deserialization exceptions and failures such as where the incoming type is not the expected type, or the deserialization throws exceptions.
Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize.
Monitor deserialization to sound alerts if a user deserializes constantly.
Isolate code that deserializes, such that it runs in very low privilege environments, such as temporary containers.
Insufficient Registration and Monitoring
Attackers can find vulnerabilities through scanning and manual investigation.
Usage of components with known vulnerabilities can put your web security at risk. When vulnerabilities are known, in most cases, vendors can fix them right way and release a patch or update. The problem is that many development teams fail to have an effective patching and tracking of 3rd party dependencies, either because they lack the awareness or because of a tight schedule.
How to prevent it?
Software projects should have a process in place to remove unused dependencies, unnecessary features, components, files, and documentation.
Continuously monitor sources like CVE and NVD for vulnerabilities in your components. Use software composition analysis tools to automate the process.
Only obtain your components from official sources and, when possible, prefer signed packages to reduce the chance of getting a modified, malicious component.
Many libraries and component do not create security patches for out-of-support or old versions, or it simply do not continue maintenance. If patching is not possible, consider deploying a virtual patch to monitor, detect or protect against the discovered issue. Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.
Have a continuous inventory of the versions of both client-side and server-side components and their dependencies using tools like versions, DependencyCheck, retire.js, and so on.
Insufficient Logging and Monitoring
Inadequate failure logging, lack of alerts and locks allow the attacker to continue testing vulnerabilities until one is exploitable. Using widely used formats such as REST, GraphQL, JSON and applying the security mechanisms already mentioned to ensure communication securrity, a strong authentication and access control list, and protections against all types of injections.
To learn more about vulnerabilities you can always search about OWASP.
How to prevent such an attack?
Ensure all logins, access control failures, and input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts.
Establish effective monitoring and alerting such that suspicious activities are detected and responded to within acceptable time periods.
Establish or adopt an incident response and recovery plan.
Use commercial and open source application protection frameworks such as OWASP AppSensor, web application firewalls such as mod_security with the OWASP Core Rule Set, and log correlation software such as ELK with custom dashboards and alerting. Penetration testing and scans by DAST tools (such as OWASP ZAP) should always trigger alerts.
Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
TRADEMARK LEGAL NOTICE
All product names, logos, and brands are the property of their respective owners in Austria or other countries. All company, product and service names used in this website are for identification purposes only. Pheniix is not affiliated with or an official partner of Cisco, CompTIA,Dimension Data, VMware, Amazon, Microsoft, Certified Ethical Hacker, (ISC)², Juniper, Wireshark, Offensive Security,Google, GNS3, F5, Python, Linux, Java, OpenStack, Vagrant, Ansible, Docker, GIT, , Blockchain or other companies. Use of these names, logos, and brands does not imply endorsement. The opinions expressed in Pheniix are personal perspectives and not those of Cisco, Dimension Data or any other company. Pheniix runs as an independent blog.
#IPSEC #ServiceProvider #SecurityCenter #InfoSec #ASASecurityDeviceManagerASDM #CCNASecurity #NationalCyberSecurityAwarenessMonth #Cybersecurity #AzureSQLdatabase #MailServer #MassachusettsInstituteofTechnology #CloudSecurity #Security #security #NationalSecurityAgencyNSA #IBMSecurity #CiscoSecurity #cybersecurity #securityflaw #CyberSecurity #CCNAWireless #CCNAIndustrial #CCNARoutingandSwitching #CCNA #CCNP #CCIE #CCIELab #CISSP #ISC2 #2019 #Pheniix #MikeGhahremani #Mike