Show HN: Check for web application security issues.(webscanservice.com)
webscanservice.com
Show HN: Check for web application security issues.
https://www.webscanservice.com
13 comments
I agree with this. I think many users won't be willing to go through with the verification step unless they have some clue about what this site actually does.
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.
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.
You're absolutely right. It's important for people to know what you're testing. Point (iii) in particular is all too real:
http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx
http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx
> Please create a "webscan.html" file with the content "scanme"
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.
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.
[deleted]
Good point. I'll fix that.
Thank you.
Doesn't work. I add the webscan.html file then scan again and get an empty response every time. URL is https://www.webscanservice.com/index.php/startscan as well I don't know if that's correct or not.
I'm sorry for the circumstances, it should work now.
I experienced the same issue.
Happy to see more people who care about security. We run a seemingly similar service, although I can't seem to get this one working. I'd definitely check out other ways of verifying the domain though, since this leaves all your customers open to the Google Hacking of searching for webscan.html for sites a hacker can toss through your system.
http://www.tinfoilsecurity.com
http://www.tinfoilsecurity.com
I'm attempting to scan a site that is accessed via https but it seems to default to http.
it just opens a blank page...(https://www.webscanservice.com/index.php/startscan)
I'm sorry if your scan might take a while, the machine just can't handle this amount of traffic.
Nothing! Just a blank page.
Where's the button to stop a scan?
You should update "Log" tab with "Scan Queued ETA: X" and/or "Scan Started". How long should it take to start scanning?
FYI: Seems to work now.
Have you actually gotten any results? I just get a nav bar with nothing in any of the tabs.
Yes. Just wait some minutes. I guess the server is under heavy load.
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.
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.
Noticed the site is super slow, if you need help hosting this just let me know.
I wasn't able to try yet because of the required file but it looks cool so far. So far I'd suggest letting people know they need to add the webcam file first. Or if that's already there make it more prominent as its not really obvious. I'm checking it out on my iPad, maybe the desktop version makes that point clearer.
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.