- by Sandeep Shetty
Penetration testing, also called pen testing, is the practice of testing a computer system, network or web application to find security vulnerabilities that a potential attacker could exploit.
Web Applications are mainly penetrated against OWASP(The Open Web Application Security Project@ – OWASP is a nonprofit foundation that works to improve the security of software) top 10 standards (https://www.cloudflare.com/learning/security/threats/owasp-top-10/) which are most common security vulnerabilities which an attacker tries to exploit. Most of the OWASP vulnerabilities can be mitigated by installing a standard Web Application Firewall on your Web Page/Front End Server/CDN.
Here I’m listing some of the issues which can be found during penetration testing of web Applications and possible fixes.
Business Rule Bypass
Lack of proper Business Rule Validation at both client and server would open ways for this kind of attack where a malicious user can turn things in his favor.
Eg: Let’s take a photography competition application, where photographs can be voted till a fixed period of time. Later photographs will be moved to the evaluation stage where the highest voted photograph wins.
Assume that a photograph can be voted by navigating to path “vote/photographId” where photographId is unique for each photograph and after the voting period all the photographs will be moved to the evaluation stage where each photograph can be evaluated in path “evaluate/photographId”.
Malicious users will try to bypass the business rule by trying methods below:
- They will note down their photographId which is in the evaluation stage.
- Malicious users will navigate to “vote/photographId” here photographId is one which is noted in step ‘a’.
- If no proper business rule validations are implemented malicious users can exploit the system to get more votes even after their voting period is over.
Privilege escalation
Most of the times developers make the mistake of sending user details in rest API calls in form of path parameter,query parameter, or request body, and granting access to resources in server side based on user data passed via API. Malicious users can spoof this by modifying and sending user data of their wish and get access to any users resources without their consent.
Eg: Getting an Identity Card scan copy of a user stored in the server by sending user email-id in API call.
We can fix this by implementing a token decode logic in server side so that only JWT token will be sent from client and all the user details are fetched from JWT token only.
Clickjacking attack
Typically, clickjacking is performed by displaying an invisible page or HTML element, inside an iframe, on top of the page the user sees. The user believes they are clicking the visible page but in fact they are clicking an invisible element in the additional page transposed on top of it.
So if your website renders inside an iFrame then it is prone to Clickjacking attack.
You can test if your website is vulnerable to clickjacking by running below HTML file in any browser
<html>
<head>
<title>Clickjacking Test</title>
</head>
<body>
<iframe src=”https://yourwebiste.com/your-page” width=”500” height=”500”></iframe>
</body>
</html>
If your website renders successfully, then it is vulnerable to clickjacking.
The X-Frame-Options response header is passed as part of the HTTP response of a web page, indicating whether or not a browser should be allowed to render a page inside a <FRAME> or <IFRAME> tag.
There are 3 possible values
- DENY – does not allow any domain to display this page within a frame.
- SAMEORIGIN – allows the current page to be displayed in a frame on another page, but only within the current domain.
- ALLOW-FROM URI – allows the current page to be displayed in a frame, but only in a specific URI – for example www.example.com/frame-page
Malicious File Upload
The web server can be compromised by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack other servers, or exploit the local vulnerabilities, and so forth. All files uploaded should be validated for type and content of the file so that no executable content gets into server or database.
Eg: Assume that you have an application which allows you to upload images, but if you are not validating uploaded files, malicious users can upload text files with any allowed image extension and mime type.
This can be prevented by validating file mime type, extension and content at both client and server.
Session continues after logout
If you are using token based authentication there is a possibility that tokens issued by your auth provider will be valid even after user logout and any malicious user that gets a hold of this token can access user resources till the expiration of the token.
Eg: Let’s consider an example of a webapp where successful sign-in returns idToken and accessTokens to the client which are valid for 1 hour and then client uses either of the tokens in “Authorization” header to make rest API calls.After 30 mins if user logout of the application, tokens still remain valid for next 30 mins and any malicious user that gets a hold of these tokens can still make API calls in the name of logged out user.
This can be fixed by storing a map of deviceId and login status in the user table so that we can update {deviceId:123,login:false} when a user logs out of a particular device and consult this map for every API call made.
Improper audit trails
Logs are very important for a production application for debugging and also for security evaluation purposes, not having proper logs of users who are accessing the application is considered a vulnerability.
Experts expect access logs to contain Action performed, User Details, IP Address, Location and Time Stamp.
Insecure Password Transmission
Passwords which are visible in plain text format during transmission to the server in the request body is considered to be one of the security risks because attackers can interpret the wire and read passwords.
It is recommended to use the “Secure Remote Password” protocol for password based authentications so that the password or any data from which can be derived is never sent to the server.
Source Code Disclosure
Source code disclosure allows malicious users to read source code of the web application by which they can understand the implementation and find any security loopholes easily.
Source code should be strictly minimized and obfuscated before it is deployed in order to make it non human readable, and non back trackable code.
Cross Origin Resource Sharing
CORS enables sharing resources between different Origins easily, not implementing CORS properly would result in security loopholes which attackers can use to exploit your application.
Basic CORS can be enabled by returning below response header for
Preflight requests
Access-Control-Allow-Origin: “Comma separated list of Origins”
Most of the developers tend to specify
Access-Control-Allow-Origin:”*”
Which means any Origin trying to access will be allowed and this will allow attackers from unknown origin have access to your resources.
Note: You can read more about CORS here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS
Missing Security Headers
There are a number of security response headers which can be returned as a result of rest API calls to a server which will make your application less vulnerable to attacks and more secure.
Some of them are listed below
- HTTP Strict Transport Security (HSTS)
- Content Security Policy (CSP)
- Cross Site Scripting Protection (X-XSS)
- X-Frame-Options
- X-Content-Type-Options
Note: You can read more about security headers here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
Contact us to find out how Techpearl can develop secure and scalable Web apps for you.
Companies will face many challenges during the product’s lifetime. A mature product manager will be able to handle the changes needed in the product, due to changing market trends and technologies and still be able to keep the product in track.