Posted in Blog, PortSwigger

PortSwigger Web Academy – 09, 10, & Server-Side Wrap-Up

It’s a little hard to believe that I’ve made it through all of the Server-Side topics of the web academy, but so I have. The last two sections were SSRF (server-side request forgery) and XXEi (XML eternal entity injection). Both were good. The SSRF section was a little shorter than I would have liked, but there were bits of SSRF in other places as well. The labs were good and introduced interesting techniques. You do need pro for the last one, but that seems reasonable.

The XXEi section was a bit odd. I did a couple of the labs earlier before doing the rest of the sections. Coming back to the rest now, they made a lot more sense. I like this section being the end of the server-side topics. I think it works well. I do think this section will be very tough if you don’t have any experience with XML. The provided solutions make it doable, but a fair amount of practice would be needed to get comfortable.

So 10 sections in, all the server-side topics down, where does that put me? From a web app pen testing standpoint, do I feel like I could sit down and do an effective pen test from memory? Meh, not without references. I think I could run a basic web app pen test. I know I’m capable of more in-depth testing, but I also recognize there are holes. Probably will fill in some of those in the client-side modules. I feel like I’m recognizing patterns and seeing possible exploits better. This was the deepest dive I’ve taken in some of these areas, which was helpful. I feel like I wanted to really internalize the info, I’d need to take a couple weeks and really focus on just this. Since my goal was more around getting ideas for detections and recognizing malicious activity in logs, I’m not as concerned with that. If I get time, I could apply this to bug bounty programs. Squeezing these in between other trainings (I did the Getting Started in Packet Decoding w/Chris Brenton and Securing the Cloud w/Andrew Krug since the last blog – reviews to come, both were very good), made this less of a priority.

If someone can prioritize these sections and combine it with bug bounty programs, I think they could come a long way very quickly. And that’s with all the client-side topics to go. I’m happy with my order for these – I’d leave XXEi to the end, but I would bump SSRF up compared to where PortSwigger has it.

  • Directory Traversal
  • Information Disclosure
  • Access Control
  • File Upload Vulnerabilities
  • Command Injection
  • Authenticaion
  • SSRF
  • Business Logic Vulnerabilities
  • SQLi
  • XXEi

I think this order builds well to allow someone with little to no experience to get to a decent level of web application pen testing fairly quickly. I would recommend doing them in a more compressed time frame than I have if you can. The content is really good for the most part. There are some gaps in the content that mostly get filled in with the labs (places where there’s a jump in the tactics or skills from the provided material to the labs). For free content put out by a company that isn’t focused on content, I’m good with that. I think if you are lost on how to do a specific lab going to the solutions will at least give you enough information to do more research. For several, just looking at the solutions was a face palm moment where I realized what I was missing. The best part for me was seeing what to look for in logs and getting ideas about ways to monitor. I would like to give the content more attention than I am, but that’s not my priority at the moment.

Posted in Blog, PortSwigger, ProfDev

PortSwigger Web Academy – 08 File Upload Vulnerabilities

This section is basically brand new. It was added after I started the Academy. The section was relatively short with enough labs to get comfortable with the basic concepts. You don’t need to know how to create the web shells yourself, but you should at least be familiar with what they are. The labs give you some practice combining techniques – I think this is incredibly valuable and appreciate when this is included. There is a little practice with ExifTool, which is just a good thing to get familiar with if you’re not already. The race condition lab was pretty cool.

I would put this section 4th so far. I feel fairly comfortable with my order for the server-side content:

  • Directory Traversal
  • Information Disclosure
  • Access Control
  • File Upload Vulnerabilities
  • Command Injection
  • Authentication
  • SSRF
  • Business Logic Vulnerabilities
  • SQLi
  • XXEi

I might switch Authentication and SSRF, but I think Authentication is a more familiar topic to those new to web app pen testing. I’ve got about half of SSRF and 2/3 of XXEi to go, but I think the above order make a lot of sense. I don’t have them ordered in terms of “value” for bug hunting or pen testing, but in the order that I think would build most logically for those just getting started. I think basic technology skills will help you get through the first few sections and provide more gradual build than the PortSwigger order. I don’t have a problem with the PortSwigger, but I think I’m coming at it from a different perspective. The content and labs are excellent, so the order probably isn’t that important. My order is just what I would recommend to people looking to transition into infosec or someone with more of a defensive focus to work on some offensive skills.

Posted in Blog, PortSwigger, ProfDev

PortSwigger Web Academy – 07 Access Control

This was a fun section. Learned some new things with headers and referrers – which is a big part of why I’m going this. Labs were a good variety and all doable with the community version. I’d probably stick this third at this point – Directory traversal, Information Disclosure, Access Control, Command Injection, Authentication, Business Logic, SQLi. I get the order PortSwigger used, but I think this order is a little more complete beginner friendly. I’ll keep tweaking as I go, but I’m pretty comfortable with the first two.

This section has a lot of labs (13) so lots of practice. All were pretty doable with the content covered in the material. No scripting for me in this section. I didn’t see a need. I like this section earlier in the learning path because it uses some very basic techniques (like examining the source code) that are beginner friendly.

A lot of the labs involved having an authenticated user, which makes sense. Not having one or an admin level user would make some of these labs much more difficult. I think you could get close with some guessing and in-depth crawling, but having creds makes a big difference.

Biggest takeaway from this section for me was “this was fun.” The labs were all pretty quick, and I just had fun doing them. Good section for building some momentum.

Posted in Blog, PortSwigger, ProfDev

PortSwigger Academy – 06 Information Disclosure

Another poke around and see what you can see class of vulnerabilities. A web crawler would definitely come in handy. I’d currently put this second (after directory traversal and before command injection) if you are just starting out. The only kind of tricky lab was the final one that involved version control and Git, but that’s quick enough to find info on.

Information disclosures are kind of like finding the end of the thread that you’ve got to keep pulling on and untangling until you get things working. Most are probably in the ‘meh’ category, but occasionally you might find a doozy. Definitely more of a starting point than a destination.

I didn’t script these out because I didn’t find it necessary. Not a value add for this section. I thought about how I could script some of it, but there are a lot of available tools to look for directories and what not, so unless I needed something specific or things were banned, I probably would let my toolset do its job for these. I did learn about some additional methods (TRACE) and headers (X-Custom-IP-Authorization) that I hadn’t messed with before. Which is why I’m doing the academy content. I know I need more experience with appsec.

I’ve also been thinking about how I can take the blue team skills I’m working on and apply them to bug bounty type work to get some additional practice. It’s not as straight forward, but I’m connecting some dots. Thinking like an attacker is good. It’s one of those things where I have to keep priorities in mind though.

Posted in Blog, PortSwigger, ProfDev

PortSwigger Academy – 05 Business Logic Vulnerabilities

I think of this type of vulnerability as kind of poke the bear and see what happens. This type of vulnerability is all about seeing how you can make the target act in an unintended fashion. I found proxying the traffic and examining what comes through critical. I would also want to map out functionality in a real-life scenario. One of the drawbacks of these labs in relation to real-world pen testing is knowing what the likely vulnerable area is and the type of vulnerability involved. There are some ways around it like the portswigger-academy-hard-mode by Staubfinger (use at your own risk), but it’s something you should keep in mind while doing the labs. I think this is partly where the practice exam comes in but thinking about how you would find the issues in apps without the prior knowledge. Depending on your experience with app development, I’d probably save this section for later. I think it fits fine here, but without some familiarity with development, some of the things in this might make less sense. The labs are very doable with the solutions, and there are some definite benefits to going through the labs to learn about this class of vulnerabilities.

Reading through the content on Portswigger, the OWASP material, and the Web Application Hacker’s Handbook on logic vulnerabilities does give a pretty good grounding in the class. That plus the labs should give a solid starting point, but I think this is one of those areas where you just kind of have to play around and see what you can find.

I didn’t do much scripting for these labs. There were some places where scripting made sense – like testing a specific parameter or a string generator – but for the most part, using Burp just made more sense. I like scripting out the labs, but it just didn’t make a lot of sense to invest the time for these labs. Other sections I could make a script that I could easily tweak to target other applications, and targeting a parameter was this type of thing. But overall, I think when you get to this point, you are manually poking and prodding to see what happens. And scripting isn’t necessarily the best way to do that. Especially when you have tools that can automate some of that for you.

Overall, valuable section but one that is a bit more complicated. It’s a class of vulnerabilities that will likely always be there, but possibly also a class where many times the effort won’t be worth the reward. I’d look at scripting out testing the parameters for things like string concatenation and exceeding maximum value to become a negative to automate some searching for logic issues. Looking for possible logic vulnerabilities while testing other classes would also be beneficial.