<p>The Open Web Application Security Project (OWASP) has provided the 10 most critical web application security threats that should serve as a minimum level for application security assessments and testing. The OWASP top 10 covers the following categories:</p>
<h2><strong>1- Injection:</strong></h2>
<p>Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. Code <em>injection</em> is the exploitation of a computer bug that is caused by processing invalid data. &#8230; Attacking <em>web</em> users with HTML/Script <em>Injection</em> (Cross-site scripting).</p>
<p><img class="aligncenter size-medium wp-image-248" src="http://www.thecloudxperts.co.uk/wp-content/uploads/2018/10/SQL-Injection-300x222.png" alt="https://www.semanticscholar.org/paper/A-Detailed-Survey-on-Various-Aspects-of-SQL-in-Web-Kindy-Pathan/12df14b506b5606222d109a6de9b6c33919ac9a4/figure/2" width="300" height="222" /></p>
<p> ;</p>
<h2><strong>2- Broken Authentication and Session Management:</strong></h2>
<p>Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.</p>
<p><img class="aligncenter size-medium wp-image-249" src="http://www.thecloudxperts.co.uk/wp-content/uploads/2018/10/session-hijacking-218x300.jpg" alt="http://red-lizzrd.blogspot.com/2016/01/broken-authentication-and-session.html" width="218" height="300" /></p>
<h2><strong>3- Cross-Site Scripting (XSS):</strong></h2>
<p>XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface websites, or redirect the user to malicious sites. You are vulnerable if you do not ensure that all user-supplied input is properly escaped, or you do not verify it to be safe via server-side input validation, before including that input in the output page.</p>
<p> ;</p>
<h2><strong>4- Insecure Direct Object References: </strong></h2>
<p>A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. The best way to find out if an application is vulnerable to insecure direct object references is to verify that <u>all</u> object references have appropriate defences.</p>
<h2><strong>5- Security Misconfiguration:</strong></h2>
<p>Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Example of application missing the proper security hardening across any part of the application stack? Including:</p>
<ol>
<li>Is any of your software out of date?</li>
<li>Are any unnecessary features enabled or installed?</li>
<li>Are default accounts and their passwords still enabled and unchanged?</li>
<li>Does your error handling reveal stack traces or other overly informative error messages to users?</li>
<li>Are the security settings in your development frameworks and libraries not set to secure values?</li>
</ol>
<h2><strong>6 -Sensitive Data Exposure:</strong></h2>
<p>The first thing you have to determine is which data is sensitive enough to require extra protection. Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. like data stores and transmitted in clear text or any old, weak crypt keys.</p>
<h2><strong>7 &#8211; Missing Function Level Access Control:</strong></h2>
<p>Applications need to perform the access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization. You can test this by Using a proxy, browse your application with a privileged role. Then revisit restricted pages using a less privileged role. If the server responses are alike, you&#8217;re probably vulnerable. Some testing proxies directly support this type of analysis.</p>
<h2><strong>8- Cross-Site Request Forgery (CSRF):</strong></h2>
<p>A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. An alternate defence is to require the user to prove they intended to submit the request, either through reauthentication, or some other proof they are a real user (e.g., a CAPTCHA).</p>
<h2><strong>9- Using Components with Known Vulnerabilities:</strong></h2>
<p>takeover. Applications using components with known vulnerabilities may undermine application defences and enable a range of possible attacks and impacts. Unfortunately, vulnerability reports for commercial or open source software do not always specify exactly which versions of a component are vulnerable. Determining if you are vulnerable requires searching these databases, as well as keeping abreast of project mailing lists and announcements for anything that might be a vulnerability.</p>
<h2><strong>10- Unvalidated Redirects and Forwards:</strong></h2>
<p>Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. The best way to find out if an application has any unvalidated redirects or forwards is to: Review the code for all uses of redirect or forward, spider the site to see if it generates any redirects and check all parameters.</p>
<p>Other than above threats you may need to consider the following which is added into OWASP list recently. Insufficient Logging&;Monitoring, Insecure Deserialization, XML External Entities (XXE).</p>
<p>Credit:</p>
<p>Gordon, Adam. The Official (ISC)2 Guide, https://www.semanticscholar.org, Microsoft, Cisco, ISC2, https://www.owasp.org</p>

