Throughout my exploration of various authorization and code execution vulnerabilities, I learned some critical lessons about common weaknesses that are often overlooked in both development and security processes. Here’s a breakdown of the key findings from my studies:
Authorization – 2
I came across something sneaky while exploring IDOR vulnerabilities. I found that simply incrementing an ID in the URL on the edit page exposed an admin secret key. It’s a basic flaw, but it’s crazy how this kind of simple manipulation can let you access sensitive data.
Authorization – 3
This one’s interesting – I saw a similar issue in a bug bounty program. Changing the URL to include .json at the end revealed the unmasked secret key. The regular page showed a masked key, but a small change like that exposed it fully. This kind of vulnerability tends to pop up in Ruby on Rails apps, so always watch out for it.
Authorization – 4
Mass assignment strikes again. In a bug bounty program, I was able to set the admin attribute to true just by manipulating the input. This kind of oversight happens when developers forget to restrict what can be mass-assigned. I’ve seen this in real-world apps too, so don’t sleep on it.
Authorization – 5
Another mass assignment example. I was able to assign an organisation_id value to my user profile, which added me to an organization I wasn’t supposed to be in. While not as common due to better security practices these days, this vulnerability still pops up in some apps, so it’s worth keeping in mind.
Code Execution – 1
This one was a bit tougher because it was new to me. It involved a PHP-based app where the goal was to execute a command or binary with a special key. The key lesson? Break the app first (with a syntax error or two), and understand the tech stack (PHP in this case). If the app uses eval(), it’s game on.
Code Execution – 2
This PHP vulnerability was more straightforward. The app used create_function() with user input, which internally calls eval(). That’s a massive red flag. The create_function() function is deprecated for a reason—if user input isn’t sanitized, an attacker can execute arbitrary code.
Code Execution – 3
This was an old PHP vulnerability involving preg_replace() with the /e modifier. It’s now deprecated, but if you find yourself on older PHP versions, this one could still bite. The vulnerability allows an attacker to inject PHP code into the replacement string and execute it. Definitely a dangerous one to watch out for.
Code Execution – 4
The assert() function in PHP was also a nasty surprise. Normally used for debugging, it evaluates strings as code if passed a string. If that string comes from user input (like $_GET['code']), it could let an attacker execute anything they want. It’s a legacy problem that’s been largely mitigated in modern PHP versions, but still worth noting for legacy apps.
Code Execution – 5
In Ruby on Rails, I ran into an issue with eval(). This one’s tricky because the input gets wrapped in a string, so you need to break out of the string context to execute code. With a carefully crafted payload, I was able to execute a system command. Remember: eval() is always a red flag.
Code Execution – 6
Here, I got to flex my Python skills. The app was vulnerable because it didn’t sanitize a URL parameter, allowing me to inject malicious code. The payload wasn’t too complicated: just a URL with a crafted string that got executed by the app. A classic example of a lack of input validation.
Code Execution – 7
Similar to the previous Python example, but here the os module wasn’t imported by default. So, I had to first import it within my payload to execute commands. It’s a good reminder that even seemingly simple vulnerabilities can be trickier in real-world applications.
Code Execution – 8
This one was a fun challenge. I had to encode a payload in base64 and then decode it within the payload itself. The trick was bypassing Flask’s URL restrictions by decoding the command. It wasn’t the hardest, but figuring out the right encoding and decoding was an interesting puzzle.
Code Execution – 9
This was hands down the hardest. I had to exploit a cgi-bin vulnerability in Perl, a language I didn’t know. The payload was tricky, but by leveraging some basic knowledge of CGI script vulnerabilities, I was able to execute my payload. Even though Perl isn’t my language of choice, it taught me the importance of understanding different tech stacks.
Key Takeaways
A lot of these vulnerabilities come down to the same old themes: lack of input sanitization, unsafe functions like eval(), and poor handling of authorization. These issues are super common, but also relatively simple to fix if you stay vigilant. It’s a reminder to always sanitize inputs, avoid risky functions like eval(), and be thorough with your authorization logic. It’s also important to understand your tech stack, especially when dealing with legacy apps. Don’t underestimate old vulnerabilities—they can still be lurking in the shadows.
Leave a Reply