How Our Team Resolved Major Security Issues with a Regulatory Reporting Platform
Within two months, our senior .NET engineers fixed every vulnerability that a penetration test found in a regulatory reporting platform.
Overview
According to the CoreSecurity Penetration Testing Report, 69% of companies run penetration tests to assess their security posture, and 70% use them to support their vulnerability management programs. A penetration test runs a simulated attack to find weaknesses that could otherwise go unnoticed. Any one of these weak spots can give an attacker access to the entire system.
One of our clients offers a regulatory reporting platform that leading organizations use to prepare and submit regulatory reports to the authorities. The platform automates collecting, validating, and submitting the data, to make sure every report is compliant. For a product like this, security is a critical concern, and a lapse can damage the company’s reputation.
A penetration test of the product revealed several vulnerabilities that could affect its workflows and put the organization’s data at risk of a breach. So, the client contacted DivIniSoft and gave our team the job of analyzing, addressing, and remediating them. Let’s see how our team approached it.
Challenges
Here’s the list of vulnerabilities that the penetration test found in the regulatory reporting platform:
- SQL injection: unsanitized user inputs could be manipulated to run malicious SQL queries, giving attackers unauthorized access to valuable records.
- Cross-Site Request Forgery (CSRF): an attacker could trick a logged-in user, for example with a link sent by email or text, into making unwanted requests such as transferring funds. If the user had administrative access, the whole application could be at risk.
- Cross-Site Scripting (XSS): attackers could inject malicious scripts that run in a user’s browser as if they came from a trusted site, and read cookies, session tokens, and other sensitive information.
- Broken access control: users could bypass authorization and reach a higher level of access, such as administrator access. For instance, a user could switch to another account just by changing the URL.
- Unrestricted file upload: the upload feature, used to submit compliance and reporting data, did not validate or restrict files and did not scan them for viruses. A malicious file could compromise the server or bring malware into the system.
- Missing rate limits: some workflows did not limit how often a user could repeat an action, which left them open to brute force, DoS and DDoS attacks, web scraping, and credential stuffing.
- User enumeration in the forgot password flow: the platform confirmed whether an entered username was valid, so attackers could collect real usernames to target or sell.
- Email flooding in the OTP flow: there was no limit on OTP email requests, so an attacker could flood a user’s inbox or automate the requests as part of a DDoS attack.
- Cookie misconfiguration: the cookies were missing the security attributes that limit their exposure, which raised the risk of session hijacking, data theft, and CSRF.
- Sessions not expiring after logout: a session stayed active after the user logged out, so anyone holding the session token could still reach the account data.
- Information disclosure in the server header: the server header revealed software versions and the technologies in use, which helps attackers find weaknesses to exploit.
- HSTS not enforced: the application did not use HTTP Strict Transport Security, so connections over plain HTTP were allowed and open to man-in-the-middle attacks.
- Vulnerable library versions: the application used outdated third-party libraries with publicly known vulnerabilities, which raised the risk of remote code execution, unauthorized access, and data breaches.
Our Approach
The platform was built in .NET. Once we understood the requirements and challenges, we quickly onboarded experienced senior .NET engineers and built a team of three as part of our professional staffing services. We included the client’s development team in the interview process, and they were happy with the engineers we proposed for the project.
With the team in place, we started the project with a structured plan. The engineers reviewed the security findings the client shared and tried to reproduce each one in the development environment. Based on what they found, they prepared the final list of issues to fix, along with a high-level plan and estimates.
Our Solution
Here’s how our team of senior engineers fixed the issues.
-
01
Root Cause Analysis
Our engineers studied each vulnerability to find its root cause in the application. For instance, the SQL injection risk came from missing input validation and parameterized queries in the backend code. CSRF was possible because sensitive forms and API requests had no anti-CSRF tokens, and cross-origin requests were not restricted through a proper SameSite cookie setting.
-
02
Application Fixes Based on OWASP Guidelines
The team then reworked the application’s structure, following the OWASP guidelines and best practices. We implemented secure authentication mechanisms, improved the security of file uploads, and introduced rate limiting and abuse prevention. We also implemented input and output encoding, and embedded CSRF tokens in all sensitive transactions.
-
03
Library Updates, Server Hardening, and Monitoring
Alongside the code fixes, we updated the libraries and dependencies to their latest versions, concealed sensitive information in the server headers, and enforced the HSTS protocol. We also deployed advanced monitoring tools to detect unusual activity patterns.
-
04
Validation with the Penetration Testing Vendor
Within two months, our team resolved all the security issues identified in the penetration test. We pushed the fixes to the UAT environment and worked with the third-party penetration testing vendor, the same one that found the issues, to test the application, validate the fixes, and confirm that every issue they had flagged was resolved.
Business Outcomes
- Resolved all the security issues from the penetration test within two months.
- Passed a retest by the same third-party penetration testing vendor that found the issues.
- Helped the client deliver the regulatory reporting product as per the decided timeline.
- Led to a multi-year agreement, with the client moving our team to one of its core development areas.
Tech Stack
Conclusion
The third-party penetration testing vendor confirmed that all the security issues were fixed, and the client delivered its regulatory reporting product as per the decided timeline. Impressed by our team’s agility and efficiency, the client moved the same team to one of its core development areas under a multi-year agreement.