How to Prevent OWASP Top 10 Vulnerability

How to Prevent Owasp Top 10 Vulnerabilities

Introduction to OWASP Top 10

The Open Web Application Security Project, or OWASP, may be a nonprofit that strives to teach the cybersecurity industry (its practitioners, researchers, and developers) about prominent web application bugs and therefore the risks they present. Every three or four years, OWASP reaches bent the businesses and organizations with a high-level and wide-sweeping view of the foremost common and highest risk vulnerabilities for feedback on common and emerging threats. These contributors include pen testing companies, bug bounty organizations, and vendors and consultants that do application testing and code reviews. OWASP collects the info anonymously then ranks the vulnerabilities supported the extent of risk they present and the way urgently they believe that developers should be made conscious of their threat.

While the OWASP Top 10 aren’t the sole security issues that impact businesses and developers, they create for a pleasant rundown of bugs and attacks that teams should keep top of mind as they build new technology or introduce new applications, services, and vendors into their businesses.

The last update from OWASP is from 2017, and though the highest 10 list could also be updated later this year, we still believe that the present version may be a good regard to guide the inspiration and preventive security initiatives that you simply champion this year. So, to begin the year, let’s dive into the 2017 OWASP Top 10 list and offer some guidance around the way to prevent these bugs and kinds of attacks from owning you in 2020.


For an injection attack to happen (as defined by OWASP), untrusted data is shipped to an interpreter as a part of a command or a question . From there, the untrusted data can trick the interpreter into executing unintended commands or accessing unauthorized data.

Injection attacks are around since nearly the dawn of hacking, but they continue to be effective. When successful, attackers can leverage injection to access all types of lucrative data damaging to businesses and individuals (like mastercard information and SSNs). Injection also can enable attackers to regulate a whole system. British ISP TalkTalk notoriously fell victim to a SQL injection attack in 2015, which affected approximately 150,000 users.

To Prevent: For client-side injection (e.g., XSS), our recommendation is contextual output encoding. except for server-side injection (e.g., SQLi), prepared statements may be a reasonable solution. Essentially, it doesn’t hurt to treat all user data as untrusted, either.

Broken Authentication

This vulnerability really tells you what it’s about up front – it’s a category of vulnerabilities that let an attacker to “either capture or bypass the authentication methods that are employed by an internet application” because the authentication in situ is broken.

It’s often caused by improperly implemented authentication, which may cause an attacker accessing otherwise restricted resources. this will end in the compromise of sensitive information, like password and keys. Additionally, an attacker could use this to leverage other flaws to assume users’ identities.

To Prevent: Implement multi-factor authentication when possible, institute a robust password policy, and always change default credentials (especially for admins).

TL;DR – practice good security hygiene and properly implement authentication.

Sensitive Data Exposure

The term “sensitive data exposure” is probably a more polite way of claiming “breach.” Many organizations come up short at doing their due diligence when it involves protecting the sensitive data (SSNs, financial information, health records, etc.) of their users. And when that sensitive data leaks, that’s once we see those noteworthy breaches.

To Prevent: just like the previous security risk, good security hygiene will assist you here. for instance , make sure that proper authentication and authorization are required to access sensitive data and frequently audit security standards you’ve got in situ .

XML External Entity Attack (XXE)

XXE refers to an attack vector where an application that parses XML data is that the target. When XXE is successful, user-supplied external entities are processed by the XML parser, which may cause sensitive data exposure and/or server side-request forgery (SSRF).

To Prevent: make sure that DTD is disabled in your XML parser.

Broken Access Control

The principle of least privilege is an oft-repeated adage within the security world – and for good reason. Users should only have the extent of permission their role requires. When a flaw exists that forestalls this from happening, users are ready to gain unnecessary access and broken access control occurs.

To Prevent: Is it a cop-out to mention that “proper access control” is that the solution? Because it’s . Implementing role-based access control and abiding by the principle of least privilege will aid tremendously. it’s going to seem simple, yet it’s something that numerous organizations continually get wrong.

Security Misconfiguration

Misconfiguration: a standard , often overlooked threat for several businesses. Simply put, configuring anything in your environment incorrectly will put you in danger . and therefore the more complex your environment happens to be, the more opportunities there are for misconfiguration.

To Prevent: Two useful preventative measures are to regularly audit your software and have a robust application architecture. Segmentation can help security misconfiguration from happening, but it’s by no means a panacea.

Cross-site Scripting (XSS)

XSS occurs when an internet application is manipulated to incorporate malicious client-side code to perform actions on behalf of end-users. There are further classifications of XSS attacks: persistent, reflected, and DOM being the most three.

Persistent XSS means attacker-controlled client-side code is stored on the target server – and as a result, this type of XSS is contained within the application itself and thus more dangerous than its counterparts. Reflected XSS is when malicious client-side code is “reflected” from an internet application executing during a user’s browser; it’s usually exploited by enticing users to click a malicious link. And DOM-based XSS happens when the XSS occurs within the document object model and isn’t apparently visible within the HTML.

To Prevent: Contextual output encoding is that the proper fix for all XSS; output encoding prevents most XSS, but taking its environmental context under consideration prevents nearly all of it. make sure that wherever user-supplied input is included into the application’s interface contextual output, encoding is employed . Perform regular security audits of your application to make sure your protections remain effective against XSS, and remediate as soon as a problem is flagged. (Spoiler alert! we’ll be covering XSS thorough in our next post.)

Also Read: Steganography Software

Insecure Deserialization

Insecure deserialization happens when the input of a serialization are often controlled by a user and therefore the serialized object is then deserialized in an insecure fashion. At its worst, insecure deserialization can cause remote code execution, which is nearly always a high or critical severity security risk.

To Prevent: To mitigate your susceptibility to insecure deserialization, a number of our advice will echo our advice to stop injection vulnerabilities – don’t trust user input. Or, confirm that your serialization mechanism permits primitive data types alone.

Using Components With Known Vulnerabilities

Insecure components are typically caused by not maintaining with patches or using legacy components in your environment that are suffering from known security issues. While this seems like more of a minor threat, actually , known vulnerabilities that have gone overlooked in terms of remediation can cause severe damage.

To Prevent: Keep an eye fixed on the foremost recent CVEs as they emerge to remain informed of the newest bugs as soon as they’re general knowledge . Patch as soon as required , and if you’ll remove any known legacy software from your environment without impacting usability, do so.

Insufficient Logging and Monitoring

This isn’t a category of vulnerability per se; it’s more of a neighborhood for improvement – because slacking during this area can have some devastating results (e.g., the Dixons Carphone Breach.)

To Prevent: Adhere to logging and monitoring best practices as closely as possible. Establish processes for reviewing internally that allow logs to be managed efficiently and incidents to be skilled during a reasonable length of your time .

Related Reading: There’s not an excellent single resource on this, but we all know from experience that if you don’t have logging and monitoring in situ , you don’t have the visibility needed to even know you were attacked or breached. These are a number of the foundational security measures that companies got to tidy to be confident that their attack surface is secured.

Following basic security hygiene tips and thoughtfully considering the way to configure tools and the way to handle access control can block many of the foremost common threats to your environment. Attackers usually choose the tried-and-true methods of attack that are rock bottom effort and therefore the easiest method into a business. From that foothold, they’ll pivot into new areas with more sensitive data or employ methods of gaining additional access thereto sensitive data. Every rough edge you’ll smooth will dissuade attackers from continuing to pursue your assets and can further establish your environment as secure.

While you won’t stop every emerging threat or zero-day with these basics, you’d be surprised at how often they work to stop the kinds of attacks that we see daily in our assessments, including those highlighted within the OWASP Top 10.

Frequently Ask Questions

Learn CEH & Think like hacker

This Blog Article is posted by

Infosavvy, 2nd Floor, Sai Niketan, Chandavalkar Road Opp. Gora Gandhi Hotel, Above Jumbo King, beside Speakwell Institute, Borivali West, Mumbai, Maharashtra 400092

Contact us –

Leave a Comment