Suggestions for things to try on web app pentest exercise with limited avenues for attack?

Hello all. First post here, hoping it is appropriate to this forum.

I am working on a web app pen test which is just a simple user login. I have one user account, and the “goal” is to try and gain access to a different users account, for which I have the username.

The web app is very simple. No javascript, super basic CSS. two form fields for login sent via POST, neither are injectable (I’ve done a ton of manual testing, and used sqlmap a bunch of times with different options).

One GET request for logout, no parameters. No form fields after logging in. No information leaked via directories or files made available when they shouldn’t be, no errors in misconfiguration, nothing so obvious.

There is one session cookie set which is a 10 digit random number. I have been thinking this is the avenue of attack, assuming it might store and load sessions from a table, but everything I have tried to inject just gets ignored by the server. No response to attempting time delays, no error responses, nothing, and sqlmap also doesn’t find anything when testing the cookie paramter.

Stuff like XSS, CSRF etc isn’t relevant at the moment.

So, suggestions for what I can try? I feel like I’ve tried everything. There must be more to try but I am at the limits of my knowledge. Can anyone give me some suggestions for more techniques I can read up on and start to attempt?

1 Like

Well, I would at first run a gobuster / dirbuster to see if you maybe find something interesting.
Hidden routes, routes you can access unauthenticated etc. You can also use more advanced wordlists and play around with the settings. If it’s a php application you want want to scan for *.php files.

You can also check for backup file artifacts: https://github.com/mazen160/bfac

Is there a password forgot function? I would check this too. They often vulnerable to IDOR attacks or the unqiue links can be decoded and you can craft your own link.

You can test if the session management is properly implemented. Login -> copy session id -> open inkognito tab -> test session cookie. If this works, you might be able to brute force the cookies for example with https://github.com/ffuf/ffuf

Then there are also some more advanced techniques you can try:

3 Likes

Is there a profile page?

IDOR, or Indirect Object Reference, is an ACL flaw and usually allows you to get access to other user profiles on all sorts of apps.

example.com/profile/49

You may find that by changing the 49 to 41 you get another users details, also pay attention to change password fields and anything that accepts a user ID, change it, see if it lets you update other peoples profiles/passwords etc.

As for the session idea - it might be linking the user agents to the sessions, checking that you have the right user agent / IP before letting you gain access.

Also - have you tried CSRF for logout? If it doesn’t take a CSRF token you can probably find CSRF.

Also - enumerate HTTP - use gobuster w/ SecLists/Discovery/Web-Content/files-large.txt, you might find some more undocumented functionality, check robots.txt too.

Awesome response <3

Ffuf is sick!

Yes it is! I found it after looking for some wfuzz alternatives. As wfuzz was dying for me with slightly larger wordlists. Even 50mb wordlists were very slow in wfuzz.

ffuf could easy handle a 2gb wordlist :wink:

2 Likes

Thanks for your reply!

I should have mentioned in OP, but I had been running dirbuster, no results, nor are there any backup file artifacts. What I’m working on is an exercise, and those types of vulnerabilities in past exercises, as this is a more advanced exercise I doubt they would repeat the same vulns. Same with backup artifacts. There is no forgot password function.

Using ffuf might be the most interesting approach, thank you for suggeesting the tool! The session id is always just a random 10 digit number. I am thinking to generate a wordlist with crunch of all 10 digit numbers and use it as a wordlist to use with ffuz.

Going to look at race conditions, request smuggling and cache poisoning also, thank you! However I know there is always one other logged in user, and the session id is a fixed 10 digit string, so I’m hoping it’s that easy.

Thanks!

No profile pages. Tried dirbuster without luck. There likely is CSRF on the logout link but it won’t help me in this case as the goal is to get access as another logged in user.

I think using ffuf that H45uK1mchi recommended is going to be key.

Thank you again all, very happy with the fast responses on the forum and looking forward to sticking around. I will update how I go!

So, brute forcing the cookie is not an option, as the web server is limiting requests, probably to prevent that very approach.

I didn’t end up trying ffuf, but wrote a small python program, and it’s going to take long. I suspect the cookie of the user I am trying to get gets rotated around every 10 minutes or so also. I’ll continue to look your other suggestions, but I’m feeling pretty stumped at the moment.

I know this exercise is meant to be tricky, but it’s frustrating not knowing what else I can try.

Have you checked for hidden fields in the forms?

If the cookie name has some default like PHPSESSID you don’t have to test any kind of brute forcing , you can try inject User Agent or the IP address here is a good list

    CLIENT_IP
    FORWARDED
    FORWARDED_FOR
    FORWARDED_FOR_IP
    HTTP_CLIENT_IP
    HTTP_FORWARDED
    HTTP_FORWARDED_FOR
    HTTP_FORWARDED_FOR_IP
    HTTP_PC_REMOTE_ADDR
    HTTP_PROXY_CONNECTION
    HTTP_VIA
    HTTP_XROXY_CONNECTION
    HTTP_X_FORWARDED
    HTTP_X_FORWARDED_FOR
    HTTP_X_FORWARDED_FOR_IP
    HTTP_X_IMFORWARDS
    VIA
    X_FORWARDED
    X_FORWARDED_FOR

Or you can simply use sqlmap with --risk 3 and --level 5 he will try some of that !
Or if the challenge is online share us the link and we give it a try together …