Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 5 down vote favorite
1

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?

share|improve this question

3 Answers

up vote 11 down vote

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: sysadmin-team@stackoverflow.com

You could also try some of the standard emails for a domain (e.g., webmaster@example.com)

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.

share|improve this answer
1  
+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. – Cheekysoft Feb 7 '12 at 11:55
up vote 1 down vote

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.

share|improve this answer
all i did was look at the URL bar. is that "using the site in a way other than the owner intended?" – That Guy Feb 7 '12 at 0:47
1  
"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 Feb 7 '12 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. – root Apr 5 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. – root Apr 5 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. – root Apr 5 at 20:21
show 2 more comments
up vote -1 down vote

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.

share|improve this answer
1  
I 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 Guy is held liable. – dr jimbob Feb 7 '12 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. – Taipo Feb 7 '12 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. – dr jimbob Feb 9 '12 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. – Taipo Feb 9 '12 at 19:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.