Show HN: Check for web application security issues.(webscanservice.com) |
Show HN: Check for web application security issues.(webscanservice.com) |
Some reasons to at least give broad strokes about how you're testing:
(i) Testing for some kinds of web flaws is inherently intrusive; for instance, it's very hard to reliably test for stored XSS without potentially disrupting an application for users.
(ii) Aggressive spidering will create performance issues for some clients, and "oh well you should have known better" isn't going to stanch the PR bleeding when you take someone's site down.
(iii) If you're doing authz testing, you will eventually find a site where a post-auth crawl will delete huge swaths of database entries because someone implemented "delete" as a vanilla GET link.
(iv) (To me, the most important) Lots of uninformed clients will run something like this and feel confident they've checked the "security" part of their deployment checklist; without knowing exactly what you're testing for (and ideally being up front about the things you don't test for), you can give clients a really dangerous false confidence.
After all, you're targeting users who, even if they aren't incredibly informed, at least have enough technical savvy to be running a site.
I advice you to make the contents of this file unique for each website, otherwise:
- i can check 1000s of sites for the existence of webscan.html
- enter the sites that have such a file
- see the vulnerabilities of sites I don't own.
Got some false positives though. For example "PHP Admin Application" and "PHP Debug Application" for files <root>/admin.php and <root>/debug.php which both do not exist actually.