Is this an SQL injection attack?

[Francoise]

Weedpacket;11027279 wrote:

What, like this very post you're reading right now?

Yes. There is no reason why a person would need to post a link in the Notes. If there's a reasonably simple way to prevent links from being posted, I would like to do that.

Thank you, as always, for your help.

[Francoise]

dalecosp;11027257 wrote:

*

And, to try and answer this:You'll have to decide that and write code to prevent HTML input.

---

Yes, that's exactly what I'd like to do. How could I write code to prevent HTML input?

Thank you for all your help.

On edit: Now that I'm understanding this a bit better, and looking more closely at these rogue posts, it occurs to me -- those aren't actually in the form of HTML, are they?

This one is typical: jtCQE0 liqrmjuqusma, djrpyohhcjgh, [link=http://tijlonftpzyt.com/]tijlonftpzyt[/link], http://hveyqwepvnjg.com/

There is no HTML code there, as near as I can tell. So none of the HTML-oriented solutions would work. I need to prevent the posting of anything with either the word 'link' or the abbreviation 'http'.

Do you know of any solution just at that level?

[laserlight]

Francoise wrote:

those aren't actually in the form of HTML, are they?

Yeah, typical forum bbcode. As Weedpacket suggested, these could be probing attempts, so at some point you might actually get HTML.

Francoise wrote:

I need to prevent the posting of anything with either the word 'link' or the abbreviation 'http'.

That is easy to do, but also easy to get a false positive, e.g., "link" could be in valid user input. If you are sure that no one will ever discuss HTTP, then probably a (case insensitive) check for that would be fine, but a check for "http://" and "https://" may be more prudent for catching the common cases that you are seeing now.

[Francoise]

laserlight;11027297 wrote:

*

That is easy to do, . . .

laserlight, thank you for your reply. Yes, I'd like to prevent both http and https from being entered in the database. You say it's 'easy' -- but how would I do it. (I've been googling like crazy but not coming up with anything.)

[laserlight]

[man]preg_match/man or even just [man]stristr/man could be used to check the content before saving it into the database.

[Francoise]

laserlight, great! Thank you so much for your help. 🙂

[TylerDev]

Laser light is right. regular expressions are a bit hard to get use to at first but can save you a lot of time in parsing content. I suggest that you use something along the lines of strip tags as well. Remember to brute your regular expressions with all types of encoding, slashes, and quotes. Every time that you are grabbing any user input you should try to make the decisions all on your side and not so much the clients side. An example of this would be a list of files with check boxes. You could have the script send the file name through the post request, or you could make an index system where the file names are only important to you. This can help ensure that the content that is going into your database is exactly what it is meant to be. If your site has a lot of traffic and has any type of money exchange you should be making sure to pen test your site with a variety for open source tools. A fairly well known sql injection tester by the name of sql map can help you out. Do remember though if sql map doesn't find anything that does not me you cannot be exploited. Look into running background scripts or packet monitoring. A great method I have picked up in the time i'v known php is to have a form builder function which checks all incoming instead of individuality checks on incoming var.

[laserlight]

TylerDev wrote:

I suggest that you use something along the lines of strip tags as well.

No, I suggest that you don't attempt to strip tags, unless you are very sure that the format of the input is such that such characters that could lead to valid input looking like HTML tags are not allowed, otherwise you will end up corrupting valid input. Even then, it might be better to reject the input instead of modifying it.

[bradgrafelman]

+1 with actually sanitizing and validating your inputs as appropriate rather than trying to find a blanket approach (because there isn't one; it's even worse than "jack of all trades, master of none" if you ask me). Simple example, say I come up with this rather secure password of " <mySuper$ecret>password", and say you fall victim of using some variant of garbage like:

//prevent SQL injections and stuff and things
$password = trim(strip_tags($_POST['password']));

Not only did you mangle user input, but you've now reduced my rather secure password to the word "password" for no apparent reason. (And I bet you didn't even admit to me in some sort of error/explanatory message, did you?!)

[annaharris]

To avoid SQL injection attack you have to take one small step. You have to put White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack.*

[dalecosp]

annaharris;11028295 wrote:

To avoid SQL injection attack you have to take one small step. You have to put White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack.*

I'm afraid that you're making this sound a tad oversimplified. A whitelisting approach works Just Fine(tm) in some situations, but you can't make the jump that to "if you will just whitelist you'll be fine ..."

Not that you meant to say "if you just whitelist you'll be fine", but it kind of sounds that way in your post above. 😉

[Bonesnap]

bradgrafelman;11027601 wrote:

+1 with actually sanitizing and validating your inputs as appropriate rather than trying to find a blanket approach (because there isn't one; it's even worse than "jack of all trades, master of none" if you ask me). Simple example, say I come up with this rather secure password of " <mySuper$ecret>password", and say you fall victim of using some variant of garbage like:

//prevent SQL injections and stuff and things
$password = trim(strip_tags($_POST['password']));

Not only did you mangle user input, but you've now reduced my rather secure password to the word "password" for no apparent reason. (And I bet you didn't even admit to me in some sort of error/explanatory message, did you?!)

This actually happened to me at a critical moment at work. Story time!

We were dealing with this website that was constantly being hacked (garbage text was being injected into their site for Googlebots to find). Our client was becoming increasingly aggravated with us since we were unable to find the source (even though we encouraged them to upgrade their years-old Joomla! installation and they refused - basically they were blaming us). Eventually we took the "scorched Earth" approach and deleted everything on their FTP and reuploaded the files. We also changed all their passwords, including their control panel password. We have a password scheme but I made the call that it wasn't sufficient in this case and used KeePass' password generator to generate 40 character passwords of random letters, numbers, and symbols. The passwords are stored securely so no one has to remember them or even type them in.

I changed the control panel password without issue (a success message was posted after I changed it). After I recorded the password I went to log back in and my attempt failed. Tried again. Tried the old password, still couldn't get in. By this time I'm sure the hosting company had locked the account. The "critical moment" was that we were supposed to be done in about 15 minutes (the client's deadline), or the client was going to drop us. We tried contacting the hosting company but they couldn't do anything for us except send out a password retrieval email to whoever was on the account - which included the client contact we were dealing with directly (the one who gave us the deadline). So my boss had to call him and twist facts to try to keep the heat off us while getting him to forward us the password retrieval email.

I got the email and the password looked the same but was able to log in with it. I was perplexed, but on a tight timeline so I finished up my work and the crisis with the client was averted (kind of - payment is still pending). I went back and looked at the password that was in the email and noticed it was 1 character short - only 39 characters. Lining them up in Notepad I noticed the password that was in the email had a backslash stripped from it (forward slashes were okay). I relayed this info to my boss because I wanted to make sure he knew I didn't mess up. I couldn't believe it, though. This was a major hosting company (not GoDaddy) that we had used and still do use quite a bit. I sent a strongly worded email to them explaining the poor practice this was and the situation it had put us in. Never heard from them.

TL;DR: Popular hosting company stripped backslashes from their control panel password without notice and I couldn't get back in while in the middle of fixing our biggest client's website who was threatening to drop us.

So yeah. Absolutely do not do this. There is no reason to strip characters or otherwise change user-supplied passwords.