Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Application Penetration Testing Cheat Sheet

jdow.io

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Web Application Penetration Testing Cheat Sheet

#31

Post by graystevens »

sbarre wrote: post #26

One of the tools listed here is DNSDumpster.com. Can someone explain how the enumeration of subdomains on a hostname works? I know that zone transfers is one way, but I looked up one of my domains and it includes a private subdomain I've never published anywhere. I checked and my DNS provider does not allow zone transfers (as far as I can tell) so I'm curious how this information is obtainable. And I mean through ord…

Zone transfers is one way, but you can also use brute force using a common word list. You can also these days use ‘OSINT’ (open source intelligence), and use things like TLS certificate transparency logs to go looking for obscure DNS names.

Re: Web Application Penetration Testing Cheat Sheet

#33

Post by sbarre »

001spartan wrote: post #27
sbarre wrote: post #26

One of the tools listed here is DNSDumpster.com. Can someone explain how the enumeration of subdomains on a hostname works? I know that zone transfers is one way, but I looked up one of my domains and it includes a private subdomain I've never published anywhere. I checked and my DNS provider does not allow zone transfers (as far as I can tell) so I'm curious how this information is obtainable. And I mean through ord…

I can't speak for DNSDumpster, but a common technique I use to do subdomain enumeration is just brute forcing with a wordlist. By enumerating with a large enough wordlist, you can discover matching subdomains for a target domain.

Yeah this is a random string of characters so it can't be that.. Also my logs show it getting queried by automated tools within a few weeks of being live, so I suspect it's due to someone's else's suggestion that a DNS resolver somewhere is caching and sharing request data for "research" or other reasons.

Re: Web Application Penetration Testing Cheat Sheet

#34

Post by gspetr »

gerdesj wrote: post #24
mushufasa wrote: post #5

This looks cool! I have the other perspective -- I have a site that I want secured. This seems helpful for that angle also. I'd be interested if there are other resources as well that could be suggested on this thread!

I've done a bit of pen testing and the cheat sheet presented gives very good advice in one place for the basics. I'd love to see web devs use something like the procedures outlined as a final check before going for sign off. When testing your own stuff, do the heavy scanning stuff "internally". You can always deploy a throwaway Kali Linux box on the same VLAN if its justified. Now as to your question: Remember that t…

> I'd be wanting to make your accounts department send me a few thousand quid to some random account.

A few thousand? What's the rationale behind that number?

Re: Web Application Penetration Testing Cheat Sheet

#35

Post by sbarre »

MobutuPehuenche wrote: post #30
sbarre wrote: post #26

One of the tools listed here is DNSDumpster.com. Can someone explain how the enumeration of subdomains on a hostname works? I know that zone transfers is one way, but I looked up one of my domains and it includes a private subdomain I've never published anywhere. I checked and my DNS provider does not allow zone transfers (as far as I can tell) so I'm curious how this information is obtainable. And I mean through ord…

"The search relies on data from our crawls of the Alexa Top 1 Million sites, Search Engines, Common Crawl, Certificate Transparency, Max Mind, Team Cymru, Shodan and scans.io." So probably CT logs. Also, if you've ever sent a cold-cache query to a recursive resolver that didn't employ QNAME minimization (few do), it was likely harvested by pDNS replication at the TLD nameserver level and shared with a number of comme…

This seems like the most likely candidate then (a resolver that caches and shares requests or CT - which I didn't know about), because the subdomain is a random string of characters so it wouldn't have been brute-forced.

Thank you for the insights!

Re: Web Application Penetration Testing Cheat Sheet

#36

Post by 001spartan »

bigbluedots wrote: post #32

It could be just me, but it looks like running that set of automated scanning tools could itself be automated. Press button, pentest done, report sent off. There must be more to the job, what else is involved?

Automated tools can only discover so much, because there are always edge cases that tools won't be able to analyze or exploit. Human creativity is a big part of penetration testing, whether it's web application assessments or other types of penetration testing, because tools have false positives, and can't come up with creative bypasses for security measures in the way a human can.

You can definitely automate many parts of testing, especially enumeration steps, but any security professional knows that a tool is no substitute for a knowledgeable hacker.

Re: Web Application Penetration Testing Cheat Sheet

#37

Post by commandlinefan »

ufmace wrote: post #12
dennis_jeeves wrote: post #11

Can somebody tell me as to what pen testers typically earns? I once talked to a firm doing pen testing and the figures they paid were the same as any other firm would pay a midlevel developer working in a regular software dept in a corporation in that city. Assuming pen testing requires a skill level a notch or two above the 'average' developer, I would have normally assumed that ideally they would be paid significan…

I get the idea that most pen testers are entry-level and spend their time doing standard scanning and looking for standardized types of vulnerabilities using pre-built tools and techniques. The ones who can build those tools and come up with novel attacks against well-protected targets are the top of the heap. What is probably scary is just how many commercial sites can be compromised by those standard well-known tec…

> most pen testers are entry-level ... What is probably scary is just how many commercial sites can be compromised by those standard well-known techniques.

... and the thought that there's an army of underpaid, underappreciated folks who spend all day every day honing the craft to perfection.

Re: Web Application Penetration Testing Cheat Sheet

#38

Post by commandlinefan »

crowbahr wrote: post #28
ufmace wrote: post #12

Earlier quoted context omitted.

I get the idea that most pen testers are entry-level and spend their time doing standard scanning and looking for standardized types of vulnerabilities using pre-built tools and techniques. The ones who can build those tools and come up with novel attacks against well-protected targets are the top of the heap. What is probably scary is just how many commercial sites can be compromised by those standard well-known tec…

Equifax Argentina (or was it all south America?) was compromised from the admin password "password". People are incredibly oblivious to how easy they are to break and how tempting a target they are.

'We used to quip that “password” is the most common password. Now it’s “password1.” Who said users haven’t learned anything about security?' -- Bruce Schneier

Re: Web Application Penetration Testing Cheat Sheet

#39

Post by commandlinefan »

gerdesj wrote: post #24
mushufasa wrote: post #5

This looks cool! I have the other perspective -- I have a site that I want secured. This seems helpful for that angle also. I'd be interested if there are other resources as well that could be suggested on this thread!

I've done a bit of pen testing and the cheat sheet presented gives very good advice in one place for the basics. I'd love to see web devs use something like the procedures outlined as a final check before going for sign off. When testing your own stuff, do the heavy scanning stuff "internally". You can always deploy a throwaway Kali Linux box on the same VLAN if its justified. Now as to your question: Remember that t…

> gives very good advice in one place for the basics.

And it's important to remember that these are the basics. I was able to perform a privilege escalation on a site (that I was supposed to be pen testing, nothing nefarious) by using a password of something like ' admin="true" password="'. This isn't something that an automated scanner will ever uncover; this list, which is awesome, is a good starting point, but not the ending point.

Re: Web Application Penetration Testing Cheat Sheet

#40

Post by gerdesj »

gspetr wrote: post #34
gerdesj wrote: post #24

Earlier quoted context omitted.

I've done a bit of pen testing and the cheat sheet presented gives very good advice in one place for the basics. I'd love to see web devs use something like the procedures outlined as a final check before going for sign off. When testing your own stuff, do the heavy scanning stuff "internally". You can always deploy a throwaway Kali Linux box on the same VLAN if its justified. Now as to your question: Remember that t…

> I'd be wanting to make your accounts department send me a few thousand quid to some random account. A few thousand? What's the rationale behind that number?

None whatsoever - I was generalising. Incidentally, I should point out that whilst I have a fair idea of the plan of attack: I would be bloody useless at actually carrying it out 8)
Post reply on HN