Do I need to do anything special to protect myself against user input from a textarea when the input is simply stored in a session cookie?
Im selling products that can be engraved with custom text. The user is "supposed" to enter the text they would like engraved into a textarea, and this text is stored in a session cookie along with the item they chose & some other data.
Right now, I use nl2br before storing it in the session cookie, then stripslashes when I display it back out onto the page.
Do I need to do anything else to protect myself from malicious code (i.e. htmlentities, etc)?
Thanks for your input (no pun intended!)
Validate the input if you only want to allow certain characters such as a-z 0-9. If you don't want characters like < and > then validate.
As a general rule of thumb, store the input as it was entered, and do any processing before it is printed to a page or other medium. By processing, I mean run it through nl2br() and htmlentities().
Usually it's better to store the data in a neutral form i.e not processed for HTML etc because you may want to output the data to some other form in future, like XML, web services, in which case it will need to be processed differently.
Store it in a session variable, not a cookie. A session variable is stored on the server and is not accessible by browsers or anyone else. If you store it in a cookie, it can be tampered with and you will have to re-validate the input every time you want to access it because it might have changed.
If you eventually store the data in a database, you'll need to escape it for SQL Injection. The method of that will vary depending on which library is used to interface with the database, but parameterised queries or prepared statements is preferable.
The first most obvious chance for attack would be direct HTML input. Imagine someone input <script src="http://malicious.com/ddos.js" /> into your textarea. Would your PHP code output that in a way that would make it run the .js code?
Second, how does the data get to the engraver? Most common would be that it's stored in a database for later use, or maybe emailed to a queue of work for the engraver.
If you're putting into a database, you'll want to look into a wrapper like PDO that can handle cleaning input.
If you're emailing it to yourself or someone else then you'll need to take care to avoid putting dangerous information in there. I believe php's mail() function will automaticlly keep the $message from making changes to the headers. http://www.php.net/manual/en/function.mail.php
If you have some other method, let us know and there may be other concerns.
You should run htmlspecialchars() before you display the variable in the textarea box.
This will make sure that possibly evil HTML code is safely displayed inside the textarea instead of being executed.
All other places you show the variable, eg. in an e-mail or an admin interface, you should run htmlspecialchars() on it as well.
Simularily, also remember to escape the variable if saving to a database, so people are not able to mess with your database query.
(An alternative approach to doing htmlspecialchars() upon display, would be running a strip_tags() on the user's input before it is stored in the session variable. But sanitizing input on display as suggested above is a more robust way of thinking, IMHO.)
Related
I validate and sanitize all my data before inserting it into the database. Would it be considered a good or a redundant pactice to validate it when pulling it form the database before displaying it?
This boils down to how much to trust your own code. On one extreme, I could forgo the validation completely if I knew that onlyI would use the client-side interface and would never make a mistake. On the other, I could validate data in every class in case I'm working with others and they forgot to properly do their job. But what's a generally good practice in this particular case?
Input validation should be a yes/no proposition. You should not modify input and save it.
You should use Htmlentities after pulling from the DB and before showing. This is because it's better to clean data just before using it at the point of failure. This is why prepared statements work so well, because there is no external code you rely on.
Say you forget to sanitize 1 field in 1 form, then when you ouput that data to other users you have no way to see that mistake from the code that does the output (assuming its not in the same file).
The less code between the sanitizing and the end result is better.
Now that is not to say save everything and validate it later. Take an email for example, you should validate that for the proper format before saving.
But for other things you don't want to modify user input. Take a file upload. Some people will change the filename to sanitize it, replace spaces etc. This is good but I prefer to create my own filename, and then show them the origainal file name, while the one I use on the server is a hash of their username and the name of the file. They never know this, and I get clean filenames.
You start modifying user data, and it becomes a chore to maintain it. You may have to un-modify it so they can make edits to it... etc. Which means you are then doing way more work then if you just clean it when outputting it.
Take for example the simple act of replacing a users \n line returns with a <br> tag. User inputs into a text field then you change it to html and save it. (besides security reasons not to do this) when user wants to edit the data, you would have to take the <br> and replace them with \n so they can edit it. Security reasons being now you have decided that raw HTML in that field is ok and will just output the raw field, allowing someone a possibility to add their own HTML. So by modifying user data we have created more work for yourself, and we have made assumptions that the data is clean before inserting it when we output it. And we cannot see how it was cleaned when we output it.
So the answer is it depends on the data and what sanitation you are doing.
Hope that makes sense.
I guess there is not need of validating or sanitizing the data from the db as you are doing it before inserting
A attacker always plays with the data which he is sending to the server and just analyis the data coming as a response . They plays with input not with the output.So just secure your data before sending it to server or db .
I use php to manage html and now I have problem with input date in mysql.
All with my input in MySQL or update or delete in MySQL is ok but how I can make security for input data in mysql because if some one open to see my html source code with browser he can see my predefined inputs and he can change thats in html and after that enter wronk inputs in mysql.
This is my code:
Options Value: <select name="extend">
<option value="<?php $_end1;$newDate = date('Y-m-d', strtotime($_end. " + 1 month"));echo $newDate;?>">1 Month</option>
Now when if someone open browser and see my code he can replease 1 month with several month and that in MySQL.
How can I this secure and or hide that in HTML.
Thx
If you're wanting to have fields or input that can't be edited by the user, such as the current date that the form was submitted on or something along the lines of that, you need to do do all of that on the server side (not the client side). Any data that is submitted from the client side can (and you should treat it like it will) be changed.
Instead of having form fields with preset values, fields that are hidden, fields that are disabled, data that is rendered with JavaScript, or any other way you could think of storing data on the client side, do those things on the server side. You can use a PHP script to do this, seeing as you're already making use of PHP. When you submit the form it has to go to some sort of a server side script, do that logic there and submit that logic to a database.
filter all your received user input. This might be clear for free text inputs, but should be done as well for predefined values.
Easiest for extending might be to only accept a certain number. For example 1, 2 or 3.
$extend = filter_input(INPUT_POST, 'extend', FILTER_VALIDATE_INT); is the first step, but you should also check if $extend is not equal to an illegal number.
if(in_array($extend, range(1,3)){ }
input like numbers is a lot more simple to check than a range of dates.
But even when that would be needed: it is possible to make your own validation function.
It is not possible to limit the browser or the user to only send certain data in a form. Either they could use a tool in the browser to change the habits of a form element, or they could rebuild the form completely in their own htmlpage or other tool
There is very simple answer to your question - you can NOT secure html and you should not even try. Every browser is equipped with developer tools and even without browser anyone can send to your server whatever they want. This is how Internet works.
What you SHOULD do is to verify your input data on server side where user has no access. In your case you should have array of allowed inputs or function assessing if input from user is valid.
More, if you know what will be the algorithm eg. ($_end + 1month) than you do not need to get from user result but only value of $_end. You can calculate $newDate just before inserting data to database - this way user will have no way of changing it.
First of all, please be carefull with your writing, it is pretty hard to understand your problem.
Secondly, if you want to "hide" PHP code to the user, you could write your code in a different way :
You create a form in which users will be able to fill some informations, and for example a date, like in your example. If this date is an option, it can have some value, as the one you show.
Then when the user submit the file, you make a checking on the variables. If you want this form to show a price, to add some data to a database, or whatever, you do some checking to be sure that the values are correct. For example, if you want to calculate a price, you will check the date the user selected, and calculate the price from this date. With this method, even if user changed the code, they will not be able to change the checking (at least not easily).
And to conclude you show a page asking the user for confirmation. This way, he will check if the informations are correct, and you can ask to re-fill some fields if you detected some invalids values
That's hard to show some concrete code, since I don't really know what you want to do, but I hope this explanation was clear. Don't hesitate to ask some questions, I'll try to answer.
darling brother:
you have 3 method:
1: define a variables instead of 1 month
2: use encryption method for php enciding that provide encryption php cides to unformatted charachters (ionCube )
3: usin my sql encryption : MD5
Following situation: I have a form with mostly dropdown lists which I populate from a database. There's also a text input field. The form is sent via POST.
What I'm wondering is, is it really necessary to sanitize the $_POST variables (besides the text input field, of course) before putting them in an sql query?
After all, it's not really user input if it came from a drop down list that I created. With $_GET I would understand the recommendation as it would be possible to manipulate the variables being sent. But AFAIK, that's not possible with POST.
Faking a POST is as easy as faking a GET. So, YES, input sanitation is needed.
You can fake using cURL (http://php.net/manual/en/intro.curl.php), but it is even insanely easier to just edit a simple html page, copy & paste your code in it, replace the values of the dropdown with whatever value you want but keeping the address in the action property of the form tag, and then that form will send all that garbage to your unprotected script.
Yes, it's possible, so you need to sanitize your database input.
With most browsers, it'll be difficult, but you can use tools like curl to simulate POST requests, where you have free control over the contents of the variables.
I am creating a rather small web application in PHP, where a (trusted) administrator can, amongst other things, store hundreds of objects in a database. The user can enter a number of details about these objects in the form of text fields (an input element with the type attribute set to "text").
The objects with their details are echoed in the form of a table, escaped by the htmlspecialchars function. This function, however, does not prevent against the malicious use of html tags, for example, the <script> tag.
The question is whether all user entered data (every cell in the table) should be purified by something like HTMLPurifier, which is already used elsewhere in the application. And if so, what would be the best way to do it as using HTMLPurifier thousands of times, as there are many details, may cause some serious performance issues.
The objects with their details are echoed in the form of a table, escaped by the htmlspecialchars function. This function, however, does not prevent against the malicious use of html tags, for example, the <script> tag.
Yes it does. They get harmlessly and correctly output as <script>.
The question is whether all user entered data (every cell in the table) should be purified by something like HTMLPurifier
Nope. You should only use HTMLPurifier on fields where you are deliberately intending to allow the user to enter markup for direct rendering to the page, for example a comment system where the user can type <i> for italics.
For other input that you are treating as plain text, htmlspecialchars remains the right thing to do when outputting to HTML.
Everything should be checked and cleaned before you save it into database. Principle is that you DO NOT TRUST anything which is coming from user.
ALWAYS escape everything.
Or just use tools which will do that for you - like frameworks.
I would like to secure user input, if it is text input we can simply use filter_input and mysql_real_escape_string.
My question is: Do I have to use those when variables are coming from a select box? Is it possible for some crafty user to change POST values from the browser?
My select box is populated dynamically from a database. Do I still have to compare recevied data (after submit) with the database, and use mysql_real_escape_string for safety?
Absolutely, you need to confirm all data you get from the client, always.
Yes someone can alter input on any form element. Something as easy as FireBug in firefox will allow me to alter any source code on my client copy of a webpage and submit a form with my altered data.
You cannot trust anything that comes from the user. Assume everything a user sends you is evil. You need to escape everything or even better use prepared statements / parametrized queries.
You need to validate each input if you want a secured site.
You need to check if the select box field matches with your database values for surety.