The Debate - What would the solution even look like? This is likely the best approach to solving this, and it will be done in the near future, but that will be very time-consuming (and isn't always viable) and we needed a solution fast. Basically, we would check the components the user should be able to see on the server side, this information would not be sent through the network, so it couldn’t be faked. Moving the whole React app to a NextJS instance was considered, so we could count on the SSR for processing the ACL. We still had to prevent attackers from seeing pages and buttons they weren't supposed to see. We also did a sweep on other endpoints related to development productivity to confirm they were all gated behind admin access, and fixed those that weren't. Turns out we still needed that form for some tests and didn't want to delete it just yet. Obviously, the first thing we did was deleting his admin account and properly gating the endpoint he used to create the user, requiring admin access and preventing it from accepting the parameters that would give this new user admin access. I know, it was a bunch of stupid mistakes, but are all your endpoints protected? Are you SURE? Because I was “pretty sure”. He logged in with this new user and the system was in his hands. Then the hacker used the proxy to modify the body of the request, and managed to create a new user with true admin power. It was never removed, we forgot about it. It was a feature no normal users were supposed to ever see, and one that was supposed to be removed after development, so we never bothered protecting it, and since the body of the request was specifically creating a "normal user", we never stopped to think about the security implications. It was a form that allowed us to quickly create new test users. However, since the back-end validates if the person requesting administrative data or performing administrative actions is an admin, there wasn’t much he could do with this power. Now he could see some things he wasn’t supposed to see, such as restricted pages and buttons. My fault, really, as the hacker said this is a very common vector of attack of SPAs, which must rely on information passing through the network to determine what the user can see and do (such as showing up a button that only an admin should see, for example).įrom there, all the hacker had to do was figure out what-is-what in the responses to make the browser believe he was an admin (for example, changing an "isAdmin" property from "false" to "true"). It wasn't a third-party stealing or changing the information, but is was still a new layer in between that allowed for an attacker to do things the application probably isn't expecting him to be able to do, and this can break things. He could effectively fake what the API was sending back to the browser, or fake what the browser was sending to the API. This allowed him to modify any data he wanted. This proxy routes the network requests to and from the tool, and makes both ends believe it is legitimally coming from each other. However, the hacker used a specialized tool called Burp Suite to set up a proxy on his machine using the certificate on his browser. The application itself is protected using SSL certificates on both ends, so the data was pretty secure while in transit. However, there was one attack that was able to get through a particular form of man-in-the-middle attack that allowed the hacker to escalate his access level. I was confident, but I was in for a wild ride.Īll of these security measures were praised on the final report. I won’t focus on those, but I recommend you to extensively research any of the above terms you’re not familiar with. As a software engineer with some 10 years of experience under my belt, I designed both to be resistant to the usual culprits. The system is comprised of a front-end SPA built with ReactJS, and a back-end API built with Node.JS. It was the first time this system was put through such a procedure. This is a very useful tactic for cybersecurity). Recently the application I’ve been working on for little more than a year went through a “pentest” (Penetration Test, where hired ethical hackers will try to invade your application and report your weaknesses, so you can fix them. Always rely on experts when it comes to security. I recommend doing your own research on the subject, and always inviting ethical hackers to pentest your applications. I’m sharing this from the perspective of a developer who was tasked with fixing a bug. Don't forget to give a star to the repository □.ĭespite having worked as a software engineer for the past decade, I am not a cryptographer and am not a cybersec specialist. Reading the article is recommended, though, for context on why this is useful. Check this repository for a simple example in NextJS of how to achieve this.
0 Comments
Leave a Reply. |