PHP/JS: how to clean user input/output - php

For example, let's say I have a website that receives and displays user comments (text). I am concerned with vulnerabilities from receiving user submissions and also when the submissions are displayed.
Concerns:
Cross-site scripting attack
SQL injection
My question is are there more attacks that could come from user text inputs? Also, in what ways can I guard against such attacks using PHP, Javascript?
Thanks, and merry Xmas!

JavaScript is not a barrier from XSS, CSRF attacks, so you should care about server side protection. If you talk about functions then these will help you from XSS: htmlentities(), strip_tags(), utf8_decode(); and as Zar said mysql_real_escape_string will help you from SQL injection.
There are a lot of articles devoted to SQL injections, XSS, CSRF, sessions hijacking. Go to http://phpsec.org/projects/guide/ and read it all.

You can use strip_tags($var) to guard yourself against XSS.
mysql_real_escape_string($var) will give you basic SQL injection protection.

Have a look at php Filter Library, which made to clean and validate different types of data, from boolean to email addresses, functions like filter_input and filter_input_array could make your application more secure and smart.

If you are using ajax to send some form data to the server as part of url, encode them like this
encodeURIComponent(yourFormInputData);
and remember to decode them on the server side.

Related

does XSS filtering in codeigniter doesn't prevent SQL injections?

i read it some where in form that xss clean in codeigniter dosn't not prevent in sql injection and it should not be used in input but it should be used in output it is true... Please can any one explain.. then how to prevent from sql injection in codeigniter.
Thank you for replaying me..
and sorry for the bad english..
First of all, both topics are not specific to CodeIgniter.
But CodeIgniter has specific way to handle some of this. Please read https://ellislab.com/codeigniter/user-guide/general/security.html
Remember that CodeIgniter will not save you from any of these and you must understand how both of these attacks works.
It is important to understand these are two different attacks, as with any attacks, they could be coupled together. For example using a XSS/CSRF to perform a SQL injection via. a crafted link to a administrator or etc.
XSS is when the attacker can inject code to be executed on the clientside. For example placing a <script> tag in your code. This often happens if you output data which the user has provided without sanitizing it or validating it. Typically this could be their username, a post title, $_GET data and etc. There are alot more ways to get a script executed on the clientside other than a script tag, so make sure to read up on the subject.
To avoid it, always escape user inputted data, from any source.
You can read more about it https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
SQL injection is when the attacker can change the SQL query for a malicious purpose. The most common way to avoid injection is to make sure to escape every input, before passing it to a query. Using prepared statement also helps alot. In CodeIgniter, you often use the "ActiveRecord" db thing, which escapes the input for you.
You can read more about it, including examples https://www.owasp.org/index.php/SQL_Injection
You should also read https://www.owasp.org/index.php/Top_10_2013-Top_10 and become familiar with the most common attacks.

Form validation mostly in JavaScript, only security validation server-side

I am building an obscure application which is only available after an involved sign-up process, so submitting malicious data should not occur often.
I use Codeigniter 2.1 to filter all POST variables. Codeigniter uses the PHP function mysql_real_escape_string among other measures to prevent a sql injection attack through POST data.
I do all my validation client-side using JavaScript. The JavaScript validation runs well. Of course, a user could use cURL or some other utility to bypass the client-side validation, but the stock PHP validation in Codeigniter should prevent SQL injection, right?
Can I do my validation client-side and trust Codeigniter to protect the database from a SQL injection attack?
This is what codeigniter claims. You can find this in system/core/Security.php file
Sanitizes data so that Cross Site Scripting Hacks can be prevented.
This function does a fair amount of work but it is extremely thorough,
designed to prevent even the most obscure XSS attempts. Nothing is
ever 100% foolproof, of course, but I haven't been able to get
anything passed the filter.
It's pretty simple IMHO. If it uses mysql_real_escape_string you are not safe in all cases. See this answer for more information: Best way to prevent SQL Injection in PHP.
Besides the fact you are not safe it also uses outdated functions for talking to mysql.
Also: you should always do server side validation! never ever trust the client side ever!

Form stores data in mysql database - XSS vulnerability

I have a form with one textarea field. The field is set to accept anything and stores the input in the database when submitted. The code is then made public as a url ex: domain.com/asd. I'm not doing any type of strip_tags, htmlentities or any type of xss prevention.
My Question is, what harm can this possibly cause. Can a user do any type of xss to fetch information from the database during either input or output.
XSS does not make any attacks possible against your server which would not be possible without XSS. What XSS does is to enable an unauthorized user to act as an authorized user. If you don't have user authentication on your site, XSS is usually not a threat.
You might be in serious threat of stored xss attacks, Stored cross site scripting :
A Stored Cross Site Scripting vulnerability occurs when the malicious user can store some attack which will be called at a later time upon some other unknowing user. The attack is actually stored in some method to be later executed.
So, if the malicious code is in the text area and you store it. At a later point of time when you display the data stored in the db, its like you are executing the code right. Apart from this, there are a lot other ways to play with your database whenever you use the data from the textarea in your SQL query.
When you accept input from the user you should at least:
for database use PDO to prevent SQL-injections.
use filter to prevent XSS
Otherwise your code is going to be unsafe as hell.
I would recommend you to read OWASP to know more about a lot of vulnerabilities. Especially the page OWASP top 10 is a must read.

what more can I do to prevent myself from XSS injection & SQL Injection?

If my site ever goes live (don't think it will, its just a learning exercise at the moment).
I've been using mysql_real_escape_string(); on data from POST, SERVER and GET.
Also, I've been using intval(); on strings that must only be numbers.
I think this covers me from sql injection? Correct? Can i do more?
But, I'm not sure how it provides (if it provides any protection at all) from XSS injection?
Any more information on how to combat these two forms of attacks is appreciated.
I think this covers me from sql injection? Correct?
No. It makes a terrible mess of your data.
Can i do more?
Yes. You can protect your code from SQL injections.
Here is a brief explanation I've made already
Only I have to add that you should not spoil your source data arrays.
POST array has noting to do with SQL. The data may go into email, an HTML form, a file, online service, etc. Why treat it all with SQL protection?
On the other hand, you may take your data not from POST but from a file, online service, other query.
So, you have to protect not source arrays, but actual data that goes into query
Speaking of XSS, there are no simple universal rule again.
But in general, you have to use htmlspecialchars($data,ENT_QUOTES); for the every untrusted data you output as a text, and some other kinds of validations in some special cases, like filenames
Used hard coded prepared queries

Is SQL Injection possible with POST?

Sql Injection is possible if parameters are passed via GET. But is it possible via POST also. If yes, can https prevent it?
Yes, it's possible with $_POST as well as with $_GET, $_COOKIE and $_REQUEST. HTTPS will not protect you at all. You have to use some function to protect you, for example mysql_real_escape_string or use prepared statements.
All communication from the web browser should be handled as "untrusted". Other techniques you can't trust is Ajax, file uploads and JavaScript form validations (among others). All these data come directly from the web browser and should not be trusted before you have filtered them or validated the data.
The only thing you can trust is $_SESSION, provided that you ONLY put in validated data into your $_SESSION variables.
Yes you can SQL inject via POST. Anyone can change what gets send in POST requests (look up an addon for firefox called "hackbar"
No https will not help with it because it can do nothing against web application layer attacks. It only prevents man-in-the-middle attacks and sniffing.
You should escape all user-submitted data, no matter the method.
No, there isn't a difference between these two methods.
The SQL injection happens when you use user supplied input in SQL statements without sanitizing it. It doesn't matter if you received the data through GET or POST, or if it was encrypted. What matters is what you do with the input after you have it.
Nothing can protect you except sanitising your inputs, and the only completely safe way to do that is to use prepared statements. This is of course hassle, but there really is no alternative - if you develop a website and it's hacked by SQL injection because you didn't use prepared statements you pretty much are negligent as a programmer for this.
The simplest way I've found in PHP of doing this to date is to use Codesense's mysqli wrapper. It's a neat, small, class that removes much of the hassle associated with raw prepared statements, has been more than solid enough where I've used it.
Using this prepared SQL only slightly more hassle than straight SQL, so there really is no excuse for not.
https cannot protect you here. Filter you input(s)

Categories