Hello,

 

Assuming we are already connected to the MYSQL Server, we are going to store the data from the text field to the database and have it display on the users profile.

 

Question: I want to accept all characters on the keyboard, Can the following statement be flawed in anyway? If so how?

 

Im already aware of flooding and to enforce with a captcha, but is there any other way?

 

The Script:

<?php
//Collect the data
$input = isset($_POST['input']) ? mysql_real_escape_string($_POST['input']) : false;

//Insert the data
mysql_query("INSERT INTO tablename (`input`) VALUES ('".$input."')");

//Display the data
$sql = mysql_query("SELECT * FROM tablename");
while($row = mysql_fetch_array($sql)) {
echo htmlentities($row['input'], ENT_QUOTES, 'UTF-8'); 
}
?>

 

The form:

<form action="" method="post">
<input name="input" type="text" />
<input name="" type="submit" value="submit" />
</form>

 

- Shaun

Edited January 18, 201115 yr by Shaun Childerley

Make sure you either remove the tags you don't want in it or use htmlentities to escape them correctly, otherwise you could have people using malicious script code on your page or totally defacing a page

Make sure you either remove the tags you don't want in it or use htmlentities to escape them correctly, otherwise you could have people using malicious script code on your page or totally defacing a page

 

echo htmlentities($row['input'], ENT_QUOTES, 'UTF-8');

 

Ive already put htmlentities there, so this is pretty much 100% secure then?

Ah oops didn't spot that - definitely need more sleep lol

As long as you escape it to begin with like you have you can't harm your database or the code you have, and with the htmlentities you've eliminated the front end issue, but I would still say you'd be best to remove tags like the <script> tag just because there's no reason to unless you're wanting to display certain tags like on a coding site or whatever

Edited January 18, 201115 yr by Jay Gilford

Ah oops didn't spot that - definitely need more sleep lol

As long as you escape it to begin with like you have you can't harm your database or the code you have, and with the htmlentities you've eliminated the front end issue, but I would still say you'd be best to remove tags like the <script> tag just because there's no reason to unless you're wanting to display certain tags like on a coding site or whatever

 

Would HTML entities stop <script> from executing?

Edited January 18, 201115 yr by Shaun Childerley

Is there any reason you have chosen using the older mysql_* functions rather than MySQLi/PDO? Using prepared statements can result in slightly more expensive function calls, but this is outweighed by the security benefits if you're worried about SQL injection.

Is there any reason you have chosen using the older mysql_* functions rather than MySQLi/PDO? Using prepared statements can result in slightly more expensive function calls, but this is outweighed by the security benefits if you're worried about SQL injection.

 

I use MYSQLI, this is just a demonstration, I do not want to use prepared statements either.

Would HTML entities stop <script> from executing?

 

Yes, <script> </script> tags would become

<script> </script>

So it would never execute it

Yes, <script> </script> tags would become

<script> </script>

So it would never execute it

 

Good this basicly answers my question because i dont want some idiot coming along using a character that is not on the keyboard and hacking the database or script.

Is there any reason you have chosen using the older mysql_* functions rather than MySQLi/PDO? Using prepared statements can result in slightly more expensive function calls, but this is outweighed by the security benefits if you're worried about SQL injection.

Not really too sure on how true that is to be honest. If you code it well, you shouldn't have any concerns

 

@Shaun - Rule #1 - NEVER TRUST USER INPUT

if you always remember that when taking user input you'll be just fine

Not really too sure on how true that is to be honest. If you code it well, you shouldn't have any concerns

 

@Shaun - Rule #1 - NEVER TRUST USER INPUT

if you always remember that when taking user input you'll be just fine

 

Of course they are more secure. Prepared statements separate logic from data and escape all input for you - to me this is coding well, and should someone need to ask if their query is vulnerable to SQL injection attacks, they should probably take the safe route. The increase in performance is undeniable, too - one example would be the fact that the query parsing overhead is reduced by preparing the statement once, and being able to use it (n) times.

 

Can you explain why you'd disagree?

You said there were security benefits, and to me there's only one benefit and that is that it's less hassle to escape the code.

That said you have to do more then to execute the query what with binding params etc, so it's not really a win win situation

 

Prepared statements are great in theory but quite tedious to code, and if you're as paranoid about security as I am then you won't fall victim to this kind of thing with regular mysql/mysqli queries

Note that with prepared statements you can't just execute one query with 1000 inserts, you have to loop and bind each and every time, so to say it's quicker is debatable on the situation

Not really too sure on how true that is to be honest. If you code it well, you shouldn't have any concerns

 

@Shaun - Rule #1 - NEVER TRUST USER INPUT

if you always remember that when taking user input you'll be just fine

 

I never trust user input, Point being if i was to build a guest book or comment system of some kind, I want to know that aslong as htmlentities and mysqli_real_escape_string is present, the script can not be hacked in anyway.

Yeah you'll be fine. I'd also like to point out that I'm not against OOP mysqli and their prepared statements, I just don't think it's all that great compared with regular querying that's all

Yeah you'll be fine. I'd also like to point out that I'm not against OOP mysqli and their prepared statements, I just don't think it's all that great compared with regular querying that's all

 

I agree, I like things the way they are.

Note that with prepared statements you can't just execute one query with 1000 inserts, you have to loop and bind each and every time, so to say it's quicker is debatable on the situation

 

No, but the server doesn't have to hard parse the statement 1000 times to ensure it's syntax is correct like it does with a statement. I agree that if the query is simple and is executed once then the overhead of using prepared statements may be marginally slower. I have done tests with prepared statements inserting as few as 10, and as many as 5000 records, all performed better. Just my two cents, and good to get someone else's opinion on it.

I'd personally use strip_tags along side htmlentities, so it will strip all php tags/html tags coming in but also transfer things like quotes ect.. into &quot or &