I feel like I don't really understand what I'm doing when solving labs

Hello all,

So I decided to try and get into infosec as a hobby couple of months ago, after dusting off my programming skills and going through some of my old networking notes as a refresher, I did some courses for beginners in bug bounty and familiarized myself with some core tools. Then I noticed that a lot of people were suggesting PentesterLab Pro as a way for newbies to get into the infosec/bug bounty field so I decided to give it a go. Did the introductory and unix badges no problem but since I 've gotten into the essentials badge, I feel like I don’t understand what I’m doing, sure I get the gist of what I’m supposed to do and I can solve most labs by playing around a bit with burp but I don’t actually understand what I’m doing. Most of the time I’m just doing random stuff like adding some parameter or changing some values etc until something works but I don’t get why that worked and something else didn’t. For example I don’t get why adding a parameter = True in the request text works but adding it from the params tab in burp doesn’t or why setting a parameter = True doesn’t work but setting same parameter = 1 does. Or why tweaking the URL grants you access, I get how to do it but I don’t understand the concept behind it or how I would know what to do if the lab didn’t have clear instructions and hints. Sure I could google that stuff but if I just google everything, isn’t actually using PentesterLab kind of useless? I know there are videos that go with every lab as an explanation but they are more like quick solutions without much explanation and I guess they are more geared towards people with a bit more knowledge than me. Any advice on how I should approach this? Is there something I’m missing or should I just use some other resources until I’m ready for PentesterLab?

Thank you in advance!

Edit: Sorry if I make it look like I’m bashing on PentesterLab, the platform actually seems great I’m just wondering if it’s right for me atm

Sure I could google that stuff but if I just google everything, isn’t actually using PentesterLab kind of useless?

I think you should definitely be googling this stuff - but specifically googling the “Why”. PentesterLabs will show you the “what” and the “how”, and give you hints on the “why”, but fundamentally hacking is about reading and understanding the original intent of a thing versus the actual implementation, and how you’ve managed to make something to a thing it wasn’t intended to do.

If you’re not understanding the why, try to figure out what it was that you were affecting, and read up on it. Was it something in the HTTP request? Maybe you need to go read up on HTTP requests - the RFCs can be pretty authoritative sources of information.

Not sure why that parameter = True worked? Maybe you’re affecting application logic. How was the web server built? Is it a Python app, written using the Django framework? Understanding what “True” means in that context will help - maybe have a go at making a very simple Django website with an auth system, and figure out how you can circumvent the thing you just built.

Hacking sure isn’t easy.

If you have specific questions, you can hit me up on our Discord (I’m @arcwhite) and I’d be happy to help either explain, or point you to materials that might explain it!

Hey @CynicalBug,

I’d recommend that you consider starting with the Web Security Academy that PortSwigger (the makers of Burp) offer.

What’s nice about it is that they offer tutorials to explain the vuln type and offer live labs you can practice on that incrementally builds on your experience from other labs so you can piece together how it works.

Like other places you have tried, it offers a bit of gamification so you can keep track of which labs you have completed. So you can tackle the novice labs and come back to the more expert labs later as you build up your skills and confidence.

HTH. And if you need more help as you progress reach out here or on Discord.

Happy hacking!

Hi @CynicalBug!

I think you ask a very good question here…trying to understand the “why” and not just the “what.” That’s a core element of the hacker mindset and I encourage you to keep asking, “why?”

Regarding your questions about why some things work in some contexts but not in others, and vice versa – this likely comes down to what’s happening on the server side. For instance, depending on the web server platform, programming language, and web app code, ‘1’ might be considered equivalent to ‘true’ or it might not. Much of web application hacking is a matter of trying to deduce what’s happening on the server side. In any event, note your observations and keep trying other inputs to see what you can deduce based upon the results. It will probably feel like you’re floundering around at first…and that’s okay. Just keep at it and remember that every “failure” has something to offer.

I would also highly recommend setting up a home lab; even if it’s just VirtualBox on your laptop. Then go through the process of building your own web server, integrating different programming languages (e.g. PHP, Python, perl, etc.), and see if you can imitate some of the web application behavior that you’re curious about. It’s time consuming, for sure, but ultimately will pay dividends many times over.

Good luck and feel free to ping me on discord if you get stuck.

Best Regards,
nerdwell

Hi CynicalBug,

You might be wondering why you got so much great advice from some skilled individuals so quickly. I would venture to guess it’s because it’s so refreshing to see someone who cares about the ‘why’ as much (or more) than the ‘how’! While so many others are all about having the phattest word lists and how many requests they can send per second, you’re saying, “Wait a sec…why did this work?” This tells me you very likely may “have what it takes” to do this stuff.

I can only echo what’s already been said: get a lab going and build out some stuff that emulates some of what you’re working on. The ability to visualize what might be going on on the back end it’s huge so if you wrote it - no more mystery.

Good luck!

Best,
yabai

Hey @arcwhite @SilverStr @nerdwell @yabai!

Thank you all for your input, unfortunately I can only code in python and have never built an actual web application so I guess I have some reading to do ! Will definitely keep going at it and finally make the decision to actually read Web applications hackers handbook ( I thought I might be able to pull it off without having to go through a 900 page book :stuck_out_tongue: ) since it seems to also explain a lot of concepts fairly in depth.

All the best,
CynicalBug

3 Likes

While practicing labs and googling the “why’s” is definitely the way to go, I would say reading up on the basics from books are understated.
There are two books that did a great deal of help to me

  1. Web Application Architecture: Principles, Protocols and Practices
  2. Web application hackers handbook.
    While this may seem to be obvious, not many take the time to actually give these books time for a detailed read.
    It would definitely up your game. In fact doing the reverse, now that you have done some labs and messed with burp, try going through these books. There would be so many things that would make a lot of sense when reading. Web app hackers handbook might be a little dated, but core concepts are solid!
1 Like

Hey @docsan

Thank you for the reply! I have not heard of Web Application Architecture, will definitely add it to my list. I have been slowly going through Web application hackers handbook, I figured reading it in one go will not make a lot of sense so I have been following this pattern:

  1. Learn about a new vuln type using Portswigger’s Web security academy ( I find that it is better suited for beginners than PentesterLab) and do the first few labs there
  2. Start reading the corresponding chapter in Web Hackers Handbook and stop when I’m feeling out of depth
  3. Start doing the labs at PentesterLab
  4. Read the reports in Web Hacking 101
  5. Finish the chapter in Web Hackers Handbook
    So far I’ve done this process for XSS,CSRF and I’m just starting on SQL Injection!

Unrelated question: Any advice on which vulns to learn about next? Or are XSSs,CSRFs and SQL Injections enough to start hunting and slowly get into other vulns in the near future

Best,
CynicalBug

1 Like

The learning pattern you have outlined here makes a lot of sense. It’s a nice way of going about learning. Honestly my learning wasn’t this structured. I think your learning pattern is solid! :+1:

On which vulns to learn about, I ll be honest, till date I have just touched upon XSS and don’t know crap about SQL injection. I don’t know why, but I have been procrastinating on those two vulns.

Tell you what, here’s my two cents. When it comes to starting to learn vulns, most beginners start with learning XSS or CSRF or SQL inj. There’s nothing wrong with this.
I am a beginner too (doing real world bug hunting for the only for the last 11 months). But I took another route,

  1. I rather concentrated on learning how to recon well. The aim here is to increase my attack surface.
  2. Content discovery, directory and file brute forcing
  3. Learning how to map an application for end points
  4. Fuzzing end points with payloads - open redirect, path traversal and possibly ssrf ( still need some practice with these vulns though, not very successful yet). But I ll catch up.
  5. Logic bugs - I 'll go on for hours trying to know the flow of a particular pattern in the app. Do crap with the parameters.
  6. Authentication bugs
  7. CSRF
    This has been my route.
    In fact, now I am thinking I have to start learning some technical vulns, like XSS or SQL inj.

I took this route because, I honestly found it difficult to start with some technical vulns.

It is normal and healthy to feel some anxiety before an exam. Many students, however, complain about “test anxiety”, explaining that they went into a test knowing the material but that they “went blank” when they began to take the exam.

There was no doubt that the company’s targets were ambitious.1 Sales reps were required to meet with a minimum of 10 physicians and four retail pharmacies a day, allocating that time according to the potential of the target.