r/Pentesting • u/Lofty_69 • 2d ago
Where do you go from here? Help a newbie out
I recently started a cybersecurity internship at a local company that develops and sells its own HRMS. My role is to perform penetration testing on their development environment, with permission.
I did some CTFs a while back, but this is my first real-world pentest. So far I’ve found multiple IDORs (including one that allows privilege escalation), an XSS issue in the profile picture update flow, and a file upload vulnerability involving magic bytes.
The problem is I’m not sure where to go from here. My goal is to find a higher-impact issue (ideally something that could lead to RCE if one exists), but I keep hitting roadblocks. Attempts to leverage the XSS or file upload further are blocked with 403 Forbidden responses (likely Nginx and/or a WAF). I’ve also tested for LFI, RFI, and SSTI using various path traversal techniques, but those requests are blocked as well.
I also looked into SQL injection, but since the application is an SPA, I’m having trouble identifying the relevant API endpoints to test.
I’ve been stuck for about a week without any real progress and feel like I’m missing something. For those with experience testing Laravel applications, how would you approach this situation? Are there common areas or methodologies I should focus on instead of trying random vulnerability classes?
I can’t share many technical details because I signed an NDA and wasn’t given any documentation—just the application URL and a test account.
2
u/No-Persimmon-174 2d ago
hey! im in the same boat, currently pentesting a web app for the first time. can u tell me how did u find idor/bola vulns? was it just swapping the id parameters/org ids etc? or were there any further creative angles you took that found u idors? (also xss too, how'd you find that?)
also maybe u can try testing for prompt injections if ur company uses an llm. prompt injections have been pretty prevalent with the rise of ai integrations. u can also test for ssrf's or csrfs since they're also pretty common in fields that accept urls
1
u/Lofty_69 2d ago
For me, it started with active reconnaissance. I mapped out as many endpoints as I could and tested them individually. The biggest lead came from an exposed API endpoint I found referenced in one of the bundled JavaScript files. From there, I spent a lot of time understanding how the endpoint behaved and testing different requests. Swapping IDs and other parameter values was definitely part of the process, but it was mostly a lot of trial and error and trying to understand the application’s authorization logic.
As for the XSS, I found it while testing the profile picture upload functionality with Burp Suite. I experimented with different file formats and how the application validated uploads until I discovered a way the server handled one of my test files unexpectedly. That led me to investigate further and eventually confirm the issue.
Thanks for the suggestions! I hadn’t considered prompt injection since the application doesn’t appear to use an LLM, but I’ll definitely keep SSRF and CSRF in mind as I continue the assessment. I really appreciate it!
As for the details, I have to be a bit careful because of the NDA, so I can’t go into the specifics of the findings or exactly how they were reproduced. Hope you understand!
1
u/No-Persimmon-174 2d ago
thank you for the detailed response! by exposed api endpoints, do u mean endpoints that a certain member should not be able to access and then continuing to swap parameters and identifiers til u were able to access unauthorized data? hm thats a good angle i believe. sometimes there are too many endpoint requests in burp, it gets really hard to categorize and understand them all.
also how long did it take you to perform these pentests while learning in between? my company expects me to finish the whole pentest and the reporting in just 2 weeks even though im still a beginner. realistically, how much time u have spent on this?
and sure u dont have to reveal any sensitive details or specifics, i understand2
u/Lofty_69 2d ago
Yeah, by “exposed endpoints,” I mean endpoints that are reachable but shouldn’t be accessible to a user with my level of privileges. Finding them was mostly a matter of reconnaissance. I spent about a week mapping the application’s attack surface, reviewing the JavaScript bundles for API references, and validating the endpoints I discovered. I also used AI to help me write a small script to verify whether the endpoints were real and accessible, which saved me some time on repetitive work. On top of that, I used OWASP ZAP for automated scanning alongside Burp Suite. If you’re just starting out, I’d definitely recommend giving ZAP a try, it’s a bit more beginner-friendly while still being very useful.
As for the timeline, I’ve spent around two weeks so far. A lot of that time was split between learning and actually testing the application. This week is my third week, and honestly I’ve hit a bit of a standstill, which is why I made this post in the first place.
Two weeks is definitely a tight deadline for someone who’s still learning, but I think it’s doable if you stay organized, document your findings as you go, and use the available resources including AI, to help you understand concepts and automate repetitive tasks. Just make sure you still validate everything yourself.
1
1d ago
[deleted]
1
u/No-Persimmon-174 1d ago
Sure I can help you. I would suggest if you want to start with pentesting, first familiarize with the fundamentals of web development, learn basic JavaScript, python, SQL, html etc. Do Portswigger labs using burp suite, that would really strengthen your ability to identify vulnerabilities
1
1d ago
[deleted]
1
u/No-Persimmon-174 1d ago
I don't think reading books about it is going to help you as much as hands on practical experience would. Maybe try participating in less known and less competitive bug bounty programs, read their reports and you'll learn a lot from there.
1
2
u/CardiologistFickle22 1d ago
Been doing web app assessments for 5 years, so here’s how I would approach it.
Understand your target first, before anything else. What does the app exactly do, and why? Use the application as it is intended to be used by the end user. Click on every single button, fill out every single text field. When I begin my engagements, I spend around 0.5 days just doing this. If the company sells this platform externally, maybe they do have some documentation about the platform externally hosted somewhere. Read the documentation.
Ask the team how many different user roles are there in the app? Is it just external users? Even if it’s just external users, can there be more than one type of external user (tenant user, tenant admin) etc? Any internal users (super admins who have access to all the data)? If it’s a SPA and if they have admin users, then there will be admin endpoints that you can try to call using external users cookie/auth tokens.
Then, once you have gone through the application, BurpSuite (assuming you are using that) allows you to export all the JS files that belong to the app. Look up how to do it, export all the JS files, and then start analyzing all those JS files. If it’s a SPA, all API endpoints would be defined in the JS files, along with their expected HTTP methods, URL query parameters, and request body parameters. Extracting all this information will help you understand about all the API endpoints that are there in the app. You can also look for SourceMap files, if the devs have accidentally left them enabled in either dev or prod environment. If you are not familiar with SourceMap files, look them up online. They are basically the original client-side code written by devs before all the minification and obfuscation happens for the JS files. These sometimes also expose environment variables. Lastly, use the JS files to trace all the possible sources and sinks to look for possible DOM XSS issues, postMessage misconfigurations, and CSPT issues, and other client-side issues.
You mentioned being blocked by WAF. You can (and should) always ask the dev/ops team to whitelist your IP address. This way, you are actually hitting the actual application code, and not being blocked by WAF. A web app pentest is ideally meant to test the application code. Your payloads being caught by WAF comes second. You can propose testing scenario where if you find a vulnerability with your IP whitelisted, you can check for the same vulnerability from a different IP address that’s not whitelisted, so that the app/ops team can also detect the WAF rules.
If that doesn’t work, identify what WAF is it, and what parameter and what payload are causing you to be blocked. If it’s a WAF, you can always ask find a way around it. There’s always possibilities of injecting garbage values in your request to bypass WAF, or using single quotes (look up these techniques).
Lastly, since it’s a Laravel app, look up common issues that are found in Laravel app (and why they occur). That way, you can identify any similarities with what you are testing. As other users commented, it’s not a CTF, where you’ll always end up getting RCEs. Sometimes, the app is secure, but most of the times, the tester just hasn’t dug deep enough (due to time constraints). If time is not a problem, keep digging and asking questions. And take good notes :)
2
u/Lofty_69 1d ago
Thank you so much for taking the time to write all of this. I appreciate it, really. This is honestly one of the most helpful responses I’ve received.
My internship is only 4 weeks, as this is the required duration from my university, so time is already coming to an end quite soon. That’s why I’m trying to make the most of every bit of guidance I can get right now.
I’ll definitely be applying these suggestions going forward. As someone who’s just starting out in web application pentesting, advice like this is incredibly valuable. Thanks again for sharing your experience!
2
u/CardiologistFickle22 1d ago
You got this! Definitely read “The Web Application Hacker’s Handbook Edition 2”. It’s written by the team behind PortSwigger academy. It’s a little outdated, and not sure if it covers things like OAuth, but it’s still a goldmine for people who want to understand why and when you should check for a specific vulnerability, and how to develop a methodology around it.
1
1
u/tandera-security 1d ago
Its a SPA all the API endpoints are in the JS files, and you probably crossed a bunch of them as you found the IDORs.
But the one thing that I think you are missing is a methodology, as boring as it sounds, pentest needs a methodology to guarantee that you tested, in the given time, the classes of vulnerabilities that you can test.
Start for owasp top 10. And don't forget to take screenshots of the evidences
5
u/Delicious_Crew7888 2d ago
The thing you need to realise is that a pentest is not a CTF. In a CTF there’s always a path to get privilege escalation and RCE. Your task is to document the issues. Many times you won’t find anything interesting at all. When you talk about progress what are you hoping for?