How can I make HTML values safe from change by browsers
some examples
textarea
<textarea maxlength="50"></textarea>
any one can change maxlength value
and <a href="#" rel="15" >Like</a>
any one can change rel value and rel value id of post
i use event.preventDefault(); on jquery
but sometimes i need change value by jquery any help
thanks
Basically the way to look at validation is this:
Client Side Validation - can be used to provide "instant" feedback to the user. That way users have difficulty typing in too many characters or invalid values. This also gives them feedback before they move off the data entry field so they can quickly fix errors. As others have said this is NEVER a substitute for server validation
Server Side Validation - This is your actual validation. Assume everything coming from the client is suspect. You need to check for "html" characters (if you aren't escaping output later on pages). You need to check the length of the data. And of course you need to check any other business rules you might have. Repeat: Assume all input is suspect!
For those familiar with client/server programming this may seem like common sense, but its always important to keep in mind. Hope this helps some!
A better solution would be to perform your sanitation and validation server-side (such as ASP), which cannot be modified by the browser. Any HTML can be modified in the browser.
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
What I'm trying to achieve is, if there is an non empty input + another input will show up.
This is how the input looks like.
<input type="file" name="image[]" />
What I'm trying to do is something like this
if (!empty($input)){
//Add another input
}
I think that you can get the idea, I am just wondering is this achievable, since I am new in php I don't know if this is possible.
And I'm sorry if I made any grammatical mistakes English is not my native language.
Sure! By looking at $_POST and $_FILES you can get an idea whether the input contained something or not. Then you can make that if and render an additional <input> as necessary.
Note though that PHP is server side code. It runs when the form is submitted in the browser and thus the browser makes a request to the server. If you want the additional input to appear immediately, as soon as the first input is filled, you'll need to use JavaScript. That's also quite possible.
My guess is, you want interactivity. In which case, you will need to use JavaScript, which is a client side language.
You hook an event to the input, and check each time it's changed to see if it's empty. If it is, you display another input.
You can see if the file was empty by using:
if ($_FILES['image']['size'] > 0)
I'm passing user-generated HTML into a database and I'm trying to make sure that no malicious code is passed through. One of the steps I'm taking is to run passed code through pear's HTML_Safe class to remove vulnerable markup. However, one thing I've noticed is that the name attribute of submitted elements gets removed. Sure enough, when you look at the source code, name is one of the few attributes that's blacklisted by default:
http://pear.php.net/package/HTML_Safe/docs/latest/HTML_Safe/HTML_Safe.html#var$attributes
What's the danger in allowing users to pass values for name? How can values for name be used to nefarious ends? Any thoughts? If not, I'm tempted to modify the blacklist.
In HTML form elements, the name attribute is used as an identifier. Therefore, if you allow name then someone may be able to override your HTML name attributes (that you may have used) with one of their own. The first matching name found is often the one used by either Javascript or server side processing.
This would then allow someone to exploit any possible Javascript or server side form processing you may be using that references the first matching name attribute found.
It is not just form elements that can use name, but they would be the least safe ones.
Another override issue is if you are using Javascripts getElementsByName in any of your functions (as pointed out below), you could end up with a function that does not do what you expect.
Edit: Some corrections and a note about getElementsByName issue (as pointed out below).
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.)