I wrote a wordpress plugin but wordpress.org rejected it due to sanitization. According to wordpress:
"## Please sanitize your POST calls
You are not properly sanitizing your POST/GET/REQUEST calls.
All instances where $_POST data is inserted into the database, or into a file, MUST be properly sanitized for security. This also holds true for $_REQUEST calls that are processed. In addition, by sanitizing your POST data, you will lessen the possibility of XSS vulnerabilities.
Using stripslashes is not enough, you need to use the Input Validation methods, or things similar, to protect your plugin. The ultimate goal is that you should ensure that invalid data is NEVER processed."
Can some help me here to add one filter code which can sanitize all my $_POST requests, or any other way?
Thanks!
Proper protection instead of Sanitation
Input sanitation is not the correct approach to security. It might be used additionally to the proper protection mechanisms, but not on it's own.
There isn't one filter that can sanitize every input. If security would be that easy, every website would be secure.
For example, to prevent SQL injection, you need to use prepared statements when inserting data into the database.
And for XSS, you have to encode characters before printing them.
So not only do these two attacks require different actions to defend against them, they are also prevented at different times.
For WordPress, these articles should help you:
WordPress: Defend against SQL injection
WordPress: Encode against XSS
OWASP: How to Prevent XSS (list of places where encoding is not enough to prevent XSS).
Sanitation
Ok, but WordPress asked you for proper sanitation. I could imagine that they just phrased it badly, and meant that you should protect against XSS and SQL injection.
If you do want to add sanitation (in addition to - not instead of - prepared statements and encoding), check out these links:
WordPress sanitize functions
PHP filter input
Related
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.
I'm using PHP 5 with SQLite 3 class and I'm wondering if using PHP built-in data filtering function with the flag FILTER_SANITIZE_STRING is enough to stop SQL injection and XSS attacks.
I know I can go grab a large ugly PHP class to filter everything but I like to keep my code as clean and as short as possible.
Please advise.
The SQLite3 class allows you to prepare statements and bind values to them. That would be the correct tool for your database queries.
As for XSS, well that is entirely unrelated to your use of SQLite.
It's never wise to use the same sanitization function for both XSS and SQLI. For XSS you can use htmlentities to filter user input before output to HTML. For SQLI on SQLite you can either use prepared statements (which is better) or use escapeString to filter user input before constructing SQL queries with them.
If you don't trust your own understanding of the security issues enough to need to ask this question, how can you trust someone here to give you a good answer?
If you go down the path of stripping out unwanted characters sooner or later you're going to be stripping out characters that users want to type. It's better to encode for the specific context that the data is used.
Check out OWASP ESAPI, it contains plenty of encoding functions. If you don't want to pull in that big of a library, check out what the functions do and copy the relevant parts to your codebase.
If you are just trying to build a simple form and dont want to introduce any heavy or even light frameworks, then go with php filters + and use PDO for the database. This should protect you from everything but cross site request forgeries.
FILTER_SANITIZE_STRING will remove HTML tags not special characters like &. If you want to convert a special character to entity code prevent malicious users to do anything.
filter_input(INPUT_GET, 'input_name', FILTER_SANITIZE_SPECIAL_CHARS);
OR
filter_input($var_name, FILTER_SANITIZE_SPECIAL_CHARS);
If you want to encode everything it's worth using for
FILTER_SANITIZE_ENCODED
For more info:
https://www.php.net/manual/en/function.filter-var.php
I think its good enough to secure your string data inputs, but there are many other options available which you can choose. e.g. other libraries would increase your application process time but will help you to process/parse other types of data.
I have gone through a lot of articles out there to find out a simple list of characters that can restrict a user from inputting for protecting my site against XSS and SQL Injections, but couldn't find any generic list as such.
Can someone help me out by simply giving me a list of safe or unsafe characters in this regard? I know this can be field specific but I need this for text field where I want to allow maximum possible characters.
The "black-list" approach is fraught with problems. For both SQLi and XSS, input validation against a white-list is essential i.e. define what you do expect rather than what you don't expect. Remember also that user input - or "untrusted data" - comes from many places: forms, query strings, headers, ID3 and exif tags etc.
For SQLi, make sure you're always using parametrised SQL statements, usually in the form of stored procedure parameters or any decent ORM. Also apply the "principal of least privilege" and limit the damage the account connecting to your database can do. More on SQLi here: http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-1.html
On the XSS front, always encode your output and make sure you're encoding it for the appropriate markup language it appears in. Output encoding for JavaScript is different to HTML which is different to CSS. Remember to encode not just responses which immediately reflect input, but also untrusted data stored in the database which could hold a persistent XSS threat. More on all this here: http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-2.html
I know this goes a bit beyond your original question, but the point I'm trying to make is that allowable characters is but one small part of the picture. The other practices mentioned above are arguably more important (but you should still use those white-lists as well).
Character filtering is not how you should go about security. To prevent SQL injection, use prepared statements. To prevent XSS you should escape all user input properly
Look at the implementation of xss filtering of Drupal CMS. The function has white list containing allowed HTML tags, all other stuff will be escaped.
I have the following code that adds a record to my MySQL database via PHP:
Contact is just a plain string.
$contact = mysql_real_escape_string(stripslashes($_POST["contact"]), $con);
$sql="INSERT INTO custom_downloads (contact) VALUES ('$contact')";
Is this good enough to prevent any sort of SQL injection attacks? What else can I do to cleanse the data?
Yes, mysql_real_escape_string will correctly escape the string so this is safe from SQL injection.
bluebit, your code is secure with regard that you're protecting against SQL Injection but you're not secure against things like XSS (Cross Site Scripting). This is the ability to pass Javascript into this field and then when you output it, you're outputting the Javascript.
To avoid this you can run your input through strip_tags() www.php.net/strip_tags this will remove all HTML tags from your input, thus getting rid of
Here is a nice function that you can reuse for all inputs you're receiveing from $_POST and wish to secure
$cleanInput = cleanPost($_POST['contact']);
function cleanPost($item) {
return mysql_real_escape_string(strip_tags(stripslashes($item)));
}
There is also a built-in function in PHP for handling input types called filter_var() This allows you to specify wether you want to remove HTML and such, just like strip_tags()
Hopet this you realise you need to protect against SQL Injection and XSS.
You can never be sure that contact will be a plain string -- it comes from "out there", which automatically makes it unsafe. You should never trust unsafe input, thus parameterized query is the only way to go.
See this article. Granted, it covers an uncommon situation, but it's better to be safe than sorry.
It will not protect you from javascript ; if this string is javascript, and you later display it on a web page, it could be executed.
To be protected from that, you could use htmlentities.
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)