Is there a policy on dangerous answers?

Question

I have a pretty active discussion on SO right now, about giving an answer, that could potentially harm the questioner. The question is Do I need to encode/decode query parameters between an ajax request and the php receiving that request? and discussion is in comments to my answer.

In short, the OP asks for a way to implement a really dangerous thing. I've provided an answer to the question with a lot of warnings, while Stephen told me that this is a very bad idea, and it is better to use prepared statements, and so on. He is absolutely right; I'm among those who upvoted his answer, but the question remains.

So, I would like to hear community's opinion on that topic. Should we protect others from shooting in their legs, or let them have responsibility to do it, if they want?

Update: One of my university teachers created sql-ex.ru site (long ago). The idea of that site is to allow people training their SQL skills. I won't tell much about the site, you can register and check it out yourself (it is available in english), but the whole idea is just the same: execute SQL provided by the user. Of course it is fltered, checked that it is safe, placed in a sandbox, etc. But the concept is just the same. It's rather popular resource, it is on third place in most popular russian search engine and have large and growing community. I hope this update will stimulate further discussion.

Answer 1

Should we protect others from shooting in their legs, or let them have responsibility to do it, if they want?

In the end, people are free to do whatever they want, including shooting themselves in the leg.

However, after two years of SO experience, I have come to refrain from posting code that is dangerous. The risk of it getting copy + pasted, or used by someone who doesn't speak english well and can't understand the warnings, is too great.

In my opinion, if you have code that solves the OP's problem but you think shouldn't be used, you shouldn't post it.

Answer 2

Sometimes you have to distinguish between what OP is asking, and what he/she really wants to happen. If you see that they've already chosen a treacherous path, it's up to you to help them back up, and to guide them in the right direction.

In this case, OP wants an easy way to perform SQL queries, and has decided literally run them from the address bar in the browser. Very bad practice, very dangerous. Not something we should be teaching, even if it's for an intranet site, or "no one" will ever use it, or whatever excuse is given. This isn't the kind of information you want someone to come up on after preforming a google search.

A good answer would at the very least warn of the dangers, and discourage dangerous practices. A great answer would do this, and show them a better way to achieve their real goal.

I completely agree with one of the commenters sentiments:

The level of complexity of the question, indicates the OP is not overly experienced, and thus does not truly understand the associated dangers with this approach. Saying "hey by the way this is a really dangerous idea, but hey here is the code to do it anyway" is irresponsible, IMO. Anyone who truly understands the implications of doing something like this, will not be asking such a basic question. –Stephen

My opinion: Don't give them a gun if it's obvious they don't know how to handle one. They will end up shooting themselves or someone else in the leg.

Answer 3

Stack Overflow is a Q&A website. There was a Q, and this was the correct A to that question.

In addition, as a safeguard, the answer was very clear about the issues, complexities and considerations with the entire scenario.

Let's sum that up:

• Answered the question
• Provided sound advice
• Helped the OP (in either case)

Seems like a good answer to me.

Had the answerer not made it clear that the scenario is dangerous then things would be different, but I'm getting a bit sick of the horrendous amount of noise generated around questions like that by people repeating themselves over and over again, not answering the question posed, when for all you know the OP is already well aware of the facts. Let the answer contain the appropriate warnings, and move on.

What's that? You can't imagine any use case for sending raw SQL statements over a network? Never used SQLYog or PhpMyAdmin? I wonder whether the developers of those tools had to put up with this level of utterly useless repetitive drivel as well.

---

Update 1

I pointed out that in order for this application to even be dangerous, the account under which the query runs would have to have more than SELECT permissions in the first place.

A concern from some other users was that, were this the case, the OP wouldn't be asking the question.

I find this slightly offensive. You've jumped to the baseless conclusion, essentially, that the OP is "stupid". What does MySQL permissions have to do with AJAX escaping? How can you gauge the OP's skills with one based on having posted a question about the other?

And surely, then, the most helpful approach is to include this information regarding permissions in your answer, rather than entertaining debates in the comments and not providing the answer.

---

Update 2

"Sometimes you have to distinguish between what OP is asking, and what he/she really wants to happen." I neither agree nor disagree in particular, but I do want to say this:

SO has become a cross between a support site for helping one user at a time (with their particular use case, which may end up differing from their stated requirements, as you suggest), and creating an archive of Questions and Answers. In the latter context, it's not a terribly helpful site when the answers don't actually answer the stated question. I've always been a bit torn between these two interpretations.

Answer 4

You should by all means warn them, but if they insist on doing the Bad Practice™ then it is their own problem, not yours. We've all done something wrong coding wise, and most of us learn from it. It only becomes your problem when the OP comes back with the question Halp!! Myes Customer tables is gone-berger, iz been hax0red, how do i get it back? Then you will feel a deep pang of regret and want to help the guy again because you feel you didn't warn him enough the first time.

It is also good that you voice your warnings like that, it may help the innumerable other people who read your answer and heed your warning.

In any case, he may have a valid reason for doing this - look at the Stack Exchange Data Explorer - how do you think it gets the query from the edit box in your browser to the database?

---

Edit:
I notice that Radek (the author of the question being discussed) is following this thread - excellent! And one more thing: DON'T DO IT! Never EVER execute a query verbatim from a client - even on an intranet where you think you can trust the users - no matter which statistics you look at¹ a very significant portion of data hacks or breaches come from internal staff.

¹ _{these are just some examples i cherry picked - they all tell the story in a different way yet strangely it is the same - never trust your staff}

Answer 5

There are a few different situations here.

Enough information to determine security

If you absolutely know that the answer is insecure under any and all circumstances (internal networks, localhost only access, no internet access, turned off, unplugged, in a locked room, etc) given the question, then yes, downvote it, and PLEASE comment on why.

However, keep in mind that even if the answer is insecure for the given question, future google searches may land on that page and the answer, though insecure for the question itself, may be secure enough for someone searching on those terms that falls into this question.

So even when you know it's insecure to implement a given solution under a particular set of circumstances, it is not wrong to teach someone about possible solutions that may actually have benefit, either as teaching examples, or usable under other situations.

Not enough information to determine security

In most cases we do not have any information regarding the particulars. We cannot infer, then that this is insecure in the particular way they need to use it. Some might claim that since SQL injection is problematic, then we can assume that sql access of any kind is insecure, but the language itself isn't the problem - it's who has access to craft SQL messages the system will use.

Therefore insecurity exists in a possibly gray area, depending on your point of view, but ONLY if you assume quite a bit based on a small amount of information.

So in most situations, where not enough information is provided to determine the ethics, go ahead and post the answer, or upvote the answer that, under some circumstances may be insecure, but cannot be assumed to be bad due to lack of information. A nice disclaimer is good, but not necessary.

So, largely, I'm not in favor of downvoting because your system of security and surrounding assumptions prohibits it.

But the downvote is yours to do with as you please.

If you truly find it objectionable under all circumstances, though, flag it for moderator attention so it can be deleted.

Answer 6

Actually, it's better they ask the question and they're told about the consequences. If they hadn't asked, someone would sure have found out and caused severe damage eventually.

Besides, with tools such as sqlmap, there's no hope anyway. As soon as you forget one bind variable, inlining parameters instead and your reverse-proxy does not filter anything, you may as well say good-bye to your database or to your sensitive data. And that can happen to anyone.

Answer 7

Ok, I said I wouldn't join the discusson, but I will:

We should always consider the alternatives:

Assuming for a moment that the SO community collectively comes to the conclusions that we shouldn't answer "How do I shoot myself in the foot?"-style question with "solutions".

This will result in many answers saying "don't shoot yourself in the foot, because ..." (and possibly a few who don't follow the collective conclusion, but let's assume those don't exist for now). That's all sound advice and if the questioner (and anyone else who reads the answers later on) follows it, everything is peachy.

Now fresh, unexperienced developer X has the same problem. He goes to the Googles and finds this question. He quickly scans it for code and doesn't find any that helps him. Discouraged, he leaves and posts the question on answers.yahoo.com where a helpful fellow (who doesn't know what SO is and had no chance to see this discussion) comes along and posts the complete shoot_myself_in_the_foot(boolean lethal) method for developer X to copy.

Result: Developer X is happy until he shoots himself in the foot in a production environment.

Maybe we should provide the how-to for shooting yourself in the foot in the safest possible way together with adequate reasoning on why not to shoot yourself in the foot.

Answer 8

I find this whole discussion fairly amusing, if we were to listen to the haters http://data.stackexchange.com would be disallowed.

SQL is shipped to SQL Server to run via json, which is exactly what the asker asked.

Sure, its a read only account, running on an isolated SQL Server instance on an isolated machine with heavy caching, throttling and even automatic banning ... but still ... SQL via ajax.

---

I do not think any policy can be generalized here, sometimes dangerous is an acceptable answer, sometimes it is not. It all totally depends on a huge set of circumstances.

In general I would not be offering newbies instruction that are most likely going to lead to carnage, but the right question from the right person deserves to be answered.

Answer 9

I don't want to join one side or another in this discussion, but just give one little thing to think about:

Some people here argue that the answer should not be posted based on the perceived competence level of the person asking it.

This has two problems: First, the competence level is perceived. That perception might be accurate (enough) or it might not. Maybe the questioner is much more competent than he seems, but isn't a native english speaker, or there is some other reason for the perception.

The more important problem with this is that the person asking the question is by far not the only one who will use the answer to achieve their goal. A well-written question (or a badly-written, but common one) will get hundreds of views over time. And most of those will be looking for an answer.

So if the only reason you post the answer (or not post the answer) is the perceived competence level of the person asking the question, then I strongly encourage you to reconsider this position.

Answer 10

"You can't imagine any use case for sending raw SQL statements over a network? Never used SQLYog or PhpMyAdmin? I wonder whether the developers of those tools had to put up with this level of utterly useless repetitive drivel as well." - I clearly stated that if your application is the EXCEPTION to the "don't do SQL client side" rule, you should be VERY experienced with the whole stack (i.e. any technology you're using), and thus not asking what is essentially a beginners question about URL encoding.

As for my evaluation of the OP's skills - I made a judgement based on a) the way the question was asked b) the complexity of the question and I was absolutely correct. The OP states himself: "My reason is that I am a tester and I restore (overwrite) databases few times a day. Sometimes I need to quickly insert,select,update something."

The OP needs an SQL client and a demo on how to import a pre-written SQL script, plain and simple.