This article will help you take a better insight into the security aspect of web applications and APIs written in any language e.g. react, angular, node.js, .net, python, etc.
Recently we were working on the admin portal for a chatbot application where the product was ready for MVP and had to enter the certification phase.
So we explored a few tools for security testing of private endpoints used by the portal. Zed Attack Proxy(ZAP), Wapiti, Arachni, and Burpsuite are here to name a few.
I’ll now discuss Burpsuite in more detail as that is the tool that we finally used
First, let me show you how to get started with burpsuite as a tool
- Install Burp suite community edition
- Open firefox and then go to settings
- Search proxy.
- Select Manual Proxy configuration. In HTTP Proxy, type 127.0.0.1 and type 8080 in port number.
- Check the checkbox ‘Also, use this proxy for HTTPS’
- In the ‘No proxy for’ text area, type localhost, 127.0.0.1(check image for reference)
- Select OK.
- Switch to URL http://burp/
- Click on CA certificate and download it.
- Go to settings in firefox and then switch to privacy and security tab. Scroll down to certificates and then click on view certificates.
- Import the certificate and check the checkbox ‘Trust this CA to identify websites’. Click on OK and restart Firefox.
We used the functionality of intercepting requests for the security review of our application. Follow these steps to use this feature:
- Open BurpSuite community edition.
- Select ‘Temporary project’ and then click on ‘Next’
- Select ‘Use Burp defaults’ and then click on ‘Start Burp’ button.
- Switch to Proxy tab and check the ‘Intercept is on’ button.
The intercept is on right now, this means that all the requests from the firefox browser will first arrive in burp. We can then forward or drop that request through burp itself.
Here are some ways that Burp suite helped us uncover a few critical gaps in our security:
Sensitive Data Disclosure:
In our web app, we had 2 types of users. One was a super admin user and the other was an administrator user. Super admins were given permission to view the information of all the accounts, but admins were allowed to view the information of their accounts only. But, when we performed the following steps, we found out that even admins were able to view the details of all accounts:
- We logged in the application through admin credentials.
- Switched to the tab that stored the details of his account.
- Forwarded the request from the burp interceptor after removing accountId parameter from the end point.
After receiving details of all accounts, the attacker would have further exploited our web app(will be discussed in detail in later sections)
Insecure Direct Object Reference:
Another serious issue that we found was that once the administrator was able to view the details of all accounts, he could update the features of other accounts. We followed the following steps to reach this conclusion:
- We logged in the application through admin credentials.
- Switched to the tab that stored the details of his account.
- Clicked on any of the toggle button
- Forwarded the request from the burp interceptor after changing the accountId to other accountId in the end point.
This is how the administrator of one account is able to change the information of other accounts
Creation of Arbitrary Account IDs:
In our application, the super administrator is provided with the functionality to add administrators to any account. But while adding new users, we discovered that we could change the request body of the endpoint and can replace the accountId with any arbitrary accountId. We were startled by the fact that after forwarding that request, we received true as response.
Cross-Organization Bypass:
Some endpoints didn’t have role validation and Admin of one account was able to create resources in other admin’s accounts. We performed the following steps to reach this conclusion:
- We logged in the application through admin credentials.
- Switched to the tab that stored the details of his account.
- Clicked on any Add button.
- Forwarded the request from the burp interceptor after changing the accountId to other accountId in the end point.
Passwords Can Be Reset Without Reset Token:
Whenever the user initiated the reset password flow, our portal asked the user to enter their email address. They then received an invite to their email inbox to change their password. In the invite link, there was a uuid parameter that was unique to that particular request. But it was observed that if a user has ever completed the password reset flow, then an attacker could use the password reset request to change their password to whatever they choose, i.e. even without the uuid parameter, an attacker could reset the password of any account.
Only the following accounts were safe from the attack:
- Accounts that had never initiated the password reset flow.
- Accounts who had started but not finished the password reset flow and still had an active password reset token
I have addressed only critical issues here. Few low priority issues were also discovered while penetration testing of our web app.
Overall, we were glad that we used Burp for our security review. Its configuration was easy and we didn’t have to look into its documentation for using it. The UX was fairly user-friendly.
Interested to know if your app is secure enough?
If yes then feel free to chat with our live agent at impledge.com and we will do a courtesy check for free.
Thank you !!
Impledge - Blog 