recently i was browsing a site, and i noticed that at the end of the URL it said id=168, which is a common indicator that the site is vulnerable to an SQL injection attack. i did some tests and found that i was right, that the site Was vulnerable and that any hacker that wanted to could do some serious damage. i sent them an email from their "contact us" link, informing them of the problem, and asking them to respond indicating that they received the message. it has been 3 weeks, and i have not received an answer. what is the best way to make sure that these people know about this hole in their site?
Add a comment
|
3 Answers
First, I'd do it semi-anonymously if possible. Laws against hacking are often broad and your actions could be construed as 'hacking' by a paranoid legal team/business types that are more annoyed with having to spend more on website development than having something secure.
Second, I would not explore the extent of the vulnerability due to legal issues. E.g., can I get password hashes? Can I get user data, etc.?
Third, do not disclose the vulnerability or threaten to do so to anyone not at their company; it may take weeks/months for them to get a designer to sensibly fix their existing code. (E.g., the lone developer is on vacation/incompetent/etc).
Fourth, I'd try and check to see if administrator/developer email addresses exist and contact them directly. The contact-us page could be directed to a marketing department that does not understand what SQL injection means and ignored that email. Do the html pages have any author/company listed in the source code with email contact? Or can you run a whois on the domain and find a technical contact?
whois stackexchange.com
...
TECHNICAL CONTACT INFO
Stack Exchange, Inc.
Sysadmin Team
1 Exchange Plaza
Floor 26
New York
NY
10006
US
Phone: +1.2122328280
Email Address: [email protected]
You could also try some of the standard emails for a domain (e.g., [email protected])
Finally, if none of that works, send another message via 'contact us' that links to articles that introduce what SQL injection is, what dangers it likely presents to their organization, why you noticed that their site was likely vulnerable to it (the same reason nefarious types will notice), and what they have to do to make their site protected against this specific attack.
answered Feb 6, 2012 at 21:27
-
3+1 to anonymity. To be frank, unless they've hired you to look for vuls, i really wouldn't contact them at all. There are some well known cases where people have been prosecuted for exactly this. Commented Feb 7, 2012 at 11:55
I have sent off emails like the one you did and have rarely received a reply. Think of it from their point of view: some random person told them that they were hacking their site ... How do you respond to them? If I received an email like that, I'd quickly fix the problem and not respond. I wouldn't want to escalate the 'relationship' any further in case the person contacting me wanted more than just to inform.
There is also only so much you can be responsible for. You inform as best you can, then leave it up to them. It's their site, their risk, their costs to remedy.
There is also a legal concern that you might need to address. By announcing that you used the site in a way that the owner did not intend, you could be subject to hacking laws and you could be liable for any damage that the owner found even if you did not cause it. Know the laws of your jurisdiction and that of the target site.
answered Feb 6, 2012 at 23:51
-
all i did was look at the URL bar. is that "using the site in a way other than the owner intended?" Commented Feb 7, 2012 at 0:47
-
2"i did some tests and found that i was right, that the site Was vulnerable" - that suggests you did more than glance at the address bar. id=### does not imply a vulnerability. If you thought so, than there would be no reason for the site owner to reply...– schroeder ♦Commented Feb 7, 2012 at 15:07
-
"It's their site, their risk, their costs to remedy." Well... In the majority of cases, I'd actually argue the last two points aren't true. If they have user-visible flaws, that's probably because they have the type of flaws that could affect the user. SQL injection? Means they have a database, which means they are associating the user with some form of state. Which means, at best, they're associating an IP with a browsing history, and at worst they're associating a name with a CCN and a PIN. XSS? means a user could get their information stolen by a website they never intentionally visited.– rootCommented Apr 5, 2013 at 20:16
-
Since the end user won't necessarily know how the attacker got their bank account information, or their e-mail password, or their SSN, mother's maiden name, etc., the website owner won't have to pay for what they've done. They may never even find out. And if they don't find out, they won't pay to remedy it. Their users will pay. Admins who believe it's okay to screw their users by not implementing security features should be cast back into Mount Doom.– rootCommented Apr 5, 2013 at 20:19
-
Or, if the administrator DOES know, they will at least have plausible deniability if no one informs them, so telling them forces them to choose between doing the decent thing, or risking a class action lawsuit. Which is why telling them might be worth doing. Although I can understand the motivation for not telling them- if they're litigious enough to worry about a class action lawsuit, they might be litigious enough to think about suing you.– rootCommented Apr 5, 2013 at 20:21
Not all discoveries come from poking around live sites. CMS's can be downloaded and explored, the same with addons/plugins for the various CMS's.
There is often an arrogance amongst web maintainers when it comes to the security or perception of security they may hold to but I have found most authors to be pleasant and thankful for having stuff pointed out to them.
The most curteous way is to give them a warning then move on. If they do something about it they do something about it. I have of late had curtious responses from people I have contacted, only once last year I experienced a negative reaction to raising an issue, and twice I received no reply when I pointed out an error in CMS plugins.
Generally though the accepted no frills approach is: - notify the owner/author/developer of the issue ( not just a application system user ) - if reply within a week and is courteous, then give them time to fix and release an update if it is that sort of system ( CMS, plugins etc ), then release the bug via one of the online exploit db sites if they haven't already done so themselves. - however if no reply ( even an autoresponse does it for me ) after a couple of repeat notifications and a couple of weeks of waiting, or even worse, you receive a berating from the affected system owner, then 0day it to a bugtraq or exploit database site.
If they were intentionally ignoring your notification, the 0day whilst not the most popular method of notification, generally gets the message to them one way or another.
-
1I agree the web maintainers/developers usually want to know about vulnerabilities. However, its not clear that the devs were contacted; esp if developed externally--it may take a while for the communication to get to the appropriate parties (who may not want to admit their incompetence to customers). However, -1 for suggesting posting it publicly as 0day exploit--that's dangerous advice which will increases the risk that black hats steal existing private user data and
That Guyis held liable. Commented Feb 7, 2012 at 15:13 -
It wasn't advice. It was simply noting the common practice whether we like it or not. One can ignore this common practice or notate it. My advice is the courteous approach in the preceding paragraph.– TaipoCommented Feb 7, 2012 at 23:40
-
My thought process is that its never good to publicly disclose vulnerabilities that can't be avoided by end-users. E.g., a public disclosure re exploits in firefox 3.5.0 JIT javascript compiler made sense; users can upgrade to a patched version or disable the JIT via a setting. But disclosing that one custom-designed website has vulnerabilities to SQL injection leaves the public no options (can't reconfigure their server) to fix and many services don't let you fully remove your data from them. Commented Feb 9, 2012 at 15:54
-
In a perfect world that is how things should work. However history is full of examples where developers have left bugs on the todo list indefinitely due to a cocktail of arrogance, laziness, ignorance and mediocrity. Out of frustration mostly, bug finders have turned to public releases (0days) as a means of last resort. This has lead to a common method which at times is not the best method when dealing with these issues. So in the end it is not a matter of what we think is the best way, it is an unavoidable reality. However we are both saying which is the best way.– TaipoCommented Feb 9, 2012 at 19:21