I have a form that sends info into a database table. I have it checked with a Javascript but what is the best way to stop spammers entering http and such into the database with PHP when Javascript is turned off?
You could implement a CAPTCHA on the form:
http://en.wikipedia.org/wiki/CAPTCHA
Edit: Also definitely verify form data on the server side and check for html tags etc as usual, but the CAPTCHA should help against automated spam attacks.
Never trust the client. Always validate all data on server side. JavaScript for form validation can just be an additional feature. You could start with basic PHP functions to check if the content contains certain strings you don't like, eg. "http://".
if (strpos('http://', $_POST['message']) !== false) { /* refuse */ }
You can use CSRF protection to prevent spammers, I have found it quite effective.
What it is and how it works
Another sneaky method is to include a "honeypot" field - a hidden field that should never be submitted with content. If it's filled, you know it's spam. Neither of these methods require an annoying CAPTCHA.
There are two things to consider which should be implemented in parallel (maybe there's more).
Captcha (as mentioned before)
Verify your data on server side! You wrote you do this by javascript. This is good, but the very same verification proccess should be written in PHP.
Well, for CAPTCHA you'll have to make it's verification on server side anyway. But even if you decide not to implement captcha, you should make data verification on server side.
I suggest using the htmlentities() function before doing your insert.
Obviously your insert should be done using parametrized queries to interact with the database as well. captcha is certainly an option, but it more serves to limit how often someone can post, not what they can post. Use hmtl escaping (again, the htmlentities() function) to prevent the user from inputting things you don't want.
Related
I'm new to web development and I don't know whether it's better to check that user filled out all the fields in a form by using "required" or to check it later using php with empty() and then return user to the front page. What are the upsides and downsides of each method?
I tried both of them and the only difference I could think of is the "Please fill out this field" box when using the html way.
Setting required in html tells users that a field is required and prevents someone from accidentally submitting a form with an empty field. However, people can still send the form with a missing field manually, by creating a request outside of a browser. The PHP should be able to handle that, though it can be as simple as returning an error.
In general, you should use client-side validation like required to tell users what to do, and server-side validation to prevent unintended behavior by bypassing the client.
The bottom line here is that your server-side code cannot cannot trust anything it receives from the client-side.
A web application receiving a HTTP request has no way of knowing whether that request came through a user-interface where some validation was applied to the data before sending, or if someone modified that user interface to remove some checks (which is easy in a browser if you have a little knowledge of the Developer Tools), or if (for example) it came from some sort of bot firing requests directly at your server, or if someone simply opened up PostMan and made the HTTP request by hand.
Therefore, in terms of security and validation, you must implement server-side validation and security procedures if you want to ensure the security and validity of your application and its data.
Client-side validation is great for improving the user experience and performance of your application (so that the user doesn't have to wait for a round-trip to the server before they get feedback on the validity of data they are trying to submit), but since it easily can be bypassed or disabled you cannot rely on that alone to protect your application.
Those are both necessary for making a secure and robust app. That is front-end and back-end validation.
The front-end validation makes it so the user cannot accidentally fill unwanted data into the fields shown. That ensures that users are using the app as intended.
The back-end validation makes sure that the values that are coming in are always values that are expected. What makes this different is that people can bypass front-end validation quite easily, and thus they will abuse this by inserting bad data in your app which can break your whole app completely.
It is necessary to check the validity of the data received from the user on the server, so you must set conditions for it on the server so that invalid data does not enter the database.
Also, to improve the user experience, it is better to have controls in html in addition to the server, this will even make the server not always check and reject the wrong request, so use both of them together.
I want to validate the data that the user enters in a form. I have only a username and two fields for the password. My first question is that I check the data with javascript and it works fine, but i want to check the data with php too incase javascript is not working. In case the javascript is not working the data will be checked from the php code, but my problem is that if javascript is working then the data will be checked from javascript and php too. Is this fine? Is there any way to avoid checking with php when the input data are checked by javascript? Also I am checking the inputs(username and password) for the number of characters, for characters(i don't permit special characters, only "_", "." numbers and letters in order to avoid sql injection) - how does it sound to you? Do you have any other suggestion for better validation?
Thank you in advance.
You should always do a serverside(php) validation of userinput. a clientside(javascript) validation is only good for a better user-experience. Also you should not restrict the input to some characters for mysql injection prevention, there are other reliable methods for this.
Yes, you should validate both client-side (JS) and server-side (PHP).
Do so on the client for convenience for your user and for a better user experience.
Do so on the server to prevent a malicious attack, or, as you stated, in case your user has JS disabled.
You should always perform server side validation. There is no guarantee that client-side validation (such as javascript validation) cannot be defeated. It's a simple exercise to grab a debugging tool (any many are built into browser nowadays) and circumvent javascript validation.
Typically there is nothing wrong and is even recommended to do validation in both places in Javascript and PHP.
Checking both ways is fine and definitely recommended. If you wanted to avoid checking with PHP if Javascript is enabled, you could append a hidden field to the form and check for this with PHP.
E.G.
if(!isset($_POST['js_hidden_field'])) {
// Run Validation
}
So you check for the hidden field, if it's not set then run the PHP Validation
This is actually good, you can never do too much validation in my opinion. Client side scripting can be manipulated by anyone with web development experience but server side scripting cannot.
client side scripting validation pros:
Alerts the user before submitting data allowing them to correct themselves
Makes your site look a little more sophisticated
server side validation pros:
no one can change any validation rules you have
they cannot turn off server side validation.
In short, doing both is good, it's actually better than just doing one or the other.
I have a question about security. I have a website programmed with HTML, CSS, PHP, Javascript(jQuery)...
Throughout the website, there are several forms (particularly with radio buttons).
Once a user selects and fills out the form, it takes the value from the selected radio button and sends that to the server for processing. The server also takes the values and plugs them into a database.
My concern is this:
How can I prevent someone from using a developer tool/source editor (such as Google Chrome's Debugging/Developer Tool module) and changing the value of the radio button manually, prior to hitting the submit button? I'm afraid people will be able to manually change the value of a radio button input prior to submitting the form. If they can indeed do that, it will entirely defeat the purpose of the script I am building.
I hope this makes sense.
Thank you!
John
How can I prevent someone from using a developer tool/source editor (such as Google Chrome's Debugging/Developer Tool module) and changing the value of the radio button manually, prior to hitting the submit button?
You can't. You have no control over what gets sent to the server.
Test that the data meets whatever requirements you set for it before inserting it into the database. If it isn't OK, reject it and explain the problem in the HTTP response.
Any data sent from the browser to the server can be manipulated outside of your control, including form data, url parameters and cookies. Your PHP code must know what sets of values are valid and reject the request if it doesn't look sensible.
When sending user input to the database you will want to ensure that a malicious user-entered string can't modify the meaning of the SQL query. See SQL Injection. And when you display the user-entered data (either directly in the following response, or later when you read it back out of the database) ensure that you encode it properly to avoid a malicious user-entered string executing as unwanted javascript in the user's browser. See Cross-site scripting and the prevention cheat sheet
I'll go along with Quentin answer on this.
Client-side validation should never stand alone, you'll need to have some sort of server-side validation of the input as well.
For most users, the client-side validation will save a round trip to the server, but at as you both mention, there is no guarentee that "someone" wouldn't send wrong data.
Therefore the mantra should be: Always have server-side validation
I would say that client-side validation should be used solely for the user's convenience (e.g., to alert them that they have forgotten to fill in a required field) before they have submitted the form and have to wait for it to go to the server, be validated, and then have it sent back to them for fixing. What a pain. Better to have javascript tell you right there on the spot that you've messed something up.
Server-side validation is for security.
The others said it already, you can't prevent users from tampering with data being sent to your server (Firebug, TamperData plugins, self-made tampering proxies...).
So on the server side, you must treat your input as if there were no client validation at all.
Never trust user input that enters your application from an external source. Always validate it, sanitize it, escape it.
OWASP even started a stub page for the vulnerability Client-side validation - which is funny - client-side validation seems to have confused so many people and been the cause of so many security holes that they now consider it a vulnerability instead of something good.
We don't need to be that radical - client-side validation is still useful, but regard it simply as an aid to prevent the user from having to do a server roundtrip first before being told that the data is wrong. That's right, client-side validation is merely a convenience for the user, nothing more, let alone an asset to the security of your server.
OWASP is a great resource for web security. Have a look at their section on data validation.
Some advice worth quoting:
Where to include validation
Validation must be performed on every tier. However, validation should be performed as per the function of the server executing the code. For example, the web / presentation tier should validate for web related issues, persistence layers should validate for persistence issues such as SQL / HQL injection, directory lookups should check for LDAP injection, and so on.
Follow this rule without exception.
In this scenario, I'd recommend that you use values as keys, and look those up on the server side.
Also, consider issuing a nonce in a hidden field every time someone loads a form - this will make it a bit more difficult for someone to submit data without going through your form.
If you have a lot of javascript, it's probably worth running it through an obfuscator - this not only makes it harder for hackers to follow your logic, it also makes scripts smaller and faster to load.
As always, there is no magic bullet to stop hacking, but you can try raising the bar enough to deter casual hackers, then worry about the ones who enjoy a challenge.
I want to validate a form without having to reload the entire page. I am using JavaScript at the moment, however this is massively insecure. To get round this, I want to use AJAX and a PHP script to validate the form. Does anyone know of any security risks this might have?
I also assume the AJAX method is far safer than vanilla JS, but I could be wrong?
They are exactly the same as the risks of validating with pure client side JavaScript. The only difference is that you are asking the server for some data as part of the process.
The user can override the JavaScript to submit the form no matter what the validation outcome is.
The only reason to use JavaScript at all when checking data for submission is to save the user time. If as part of that you want to do something such as asking the server if a username is taken while the user fills out the rest of the form, then great — that is quite a nice use of Ajax. Otherwise, using Ajax is pretty worthless.
If you want to do client side checking, then put all the logic you can for it on the client and avoid making HTTP requests. If you have things that can only be checked server side (because they are based on data, like the example with usernames that are already taken) then consider using Ajax for that. The client side check is the convenience check. Always do the security check server side and on the final submitted data.
Note that validating data that is actually submitted using Ajax is a different matter — since that is the final submitted data. It is doing Ajax validation as a precursor to the final submission that doesn't add any trust to the data.
All AJAX does is offload part of the process to the server, 'hidden' from the client (in the sense the functional handling of your data/variables is hidden). That said, you should be wary of the information being sent to the server, which can be captured or worse, duped. The difference with pure JS is that your functional handling is there for all to see, and potentially exploit.
Validation shouldnt need to be done server side unless you are validating DB content (i.e. uniqueness of a username etc). If you are simply validating whether something is an email, you can do this in JS, eg with a RegEx.
If you are validating DB data, make sure all DB queries variables which originate from sent (POST/GET) variables are escaped using mysql_real_escape_string to prevent SQL injection
You can validate data in AJAX as well as you can do it in pure JavaScript, but you have to re-validate it in your script after it receives the data.
Every client-side validation method can be avoided by sending POST request to your form target.
The main thing to bear in mind here is that when using AJAX you are essentially providing an interface to your database. For example, if you are checking for duplicate usernames (which you CANNOT do in javascript) or duplicate emails, so as to provide a message such as "this username is already in use ... please try another", you are providing an interface for a potential hacker to immediately check which usernames and/or emails are available. The security considerations are NOT the same as for javascript.
My advice to you on this topic is (1) Use parameterised queries to access database as someone has already suggested. (2) Implement a delay on the ajax .php page - the length depends on the scenario - I go for about 1 second (3) Execute ajax on blur, or on loosing focus, not on every keypress, (4) Implement a check in your ajax handler that ensures the request comes from the expected page (ie: not some random script a hacker wrote). (5) ONLY make the AJAX call when some other basic validation of the form element has taken place [ie: the basic javascript validation]
I hope this helps. Form validation using ajax is absolutely nothing like being even remotely similar to javascript validation. It is an interface into your database, and you need to be carefull with it.
It helps to imagine how you would hack into your own site - knowing which email addresses are registered with your site is a great place to start. So I could write a script to generate random email addresses using common words and/or names and hammer your ajax handler to obtain a list of registered email addresses to your site. I could do this quickly IF you didn't follow the advice (1)-(5) I stated above.
Once I have the emails, I just google them ... chances are that gives me a name. I can guess the username from there. So now I have username and emails. Passwords would take too long to explain, but if I can get the usernames or emails that easily ... it marks you out as a target and you will get more attention that you really want.
Im working on a registration validation system at the moment - Id be happy to share it with you if you'd like. Probably I'm missing something important !
Peace out.
I am done with validation using javascript for a form in PHP.
When is there any need for PHP validation?
javascript validation in itself ensures that all the fields are filled up. Is there a possibility to check the valid format of the inputs using javascript?
Yes
Client Side (Javascript) validation is only to help innocent users find out any errors in their forms without the need for a trip to the server and page reload.
Server side (PHP) validation is needed to prevent malicious users from submitting malformed queries to your server and gain access to your data.
Please note that client side validation only works on the forms you make. A malicious user can make her own form and submit to your server quite easily - thus completely bypassing your client side validation.
Conclusion: You need both forms of data validation.
Validation with javascript is great for useability, but without server side validation you leave yourself open to malicious input and bad data.
Javascript ensure the validation client-side but:
could be disabled
form can be submitted to your server by a "bad guy" from a custom page
so both are required IMHO
In general, a user has control over what data is submitted to a form handler, so you need to validate and sanitize it before it's safe. She might not even use a browser.
Yes, if JavaScript is disabled in client broser then server side validation is necessary.
telnet yoursite.com 80
GET /yourapp.php?name=');drop%20table%20users;-- HTTP/1.1
Host: yoursite.com
Bad things happen when you don't do server side sanitation.
Slightly less important than preventing your site from getting owned by anyone with a little bit of knowledge, not everyone will have javascript turned on, so you want to provide worthwhile error messages for them as well (not to mention, avoiding running with bad data, creating users with empty email addresses or names, as a non-malicious example).
But what is the purpose of using the both validations at the same time? Because it's extra burden for the server for validating the form inputs in php if javascript validation is successful. Can not we use a flag and set or unset it's value depending upon whether javascript validation is successful or not? And if the flag value set we will skip the php validation. Is not it possible? If it's not possible can you explain with a valid real life example? Or can a user modify the value of the flag even if we pass it in header? Waiting for some logical answers. Thank you.