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!
Related
I am just reading up about mysql injection and I wanted to confirm that if you force a user to use list options for their input that is written to mysql (and those inputs are set as readonly) is the system essentially secure from mysql injection? would one need to put in measures to protect malicious mysql injection attempts for sites developed this way?
If I understand you correct then no.
You can try to force the user but everything that the user enters, happens on the client side. Since this is on the clients side and the client has absolute control over the webpage he can manipulate it to whatever he wants or even genereate own POST or GET Requests regardless of the page he received.
There are some tools that can achieve this goal.
If you want to secure your database against SQL Injection I recommend that you use prepared statements only (How can I prevent SQL injection in PHP?)
Any countermeasures that you take have to be implemented on the server side. You should always expect that the user sends whatever will break your code and do harm to you, regardless of the "restrictions" he has to his input.
Based on the information provided in the question:
Q: ... is the system essentially secure from mysql injection?
A: No, this doesn't guarantee that the system won't be vulnerable to SQL Injection.
Q: would one need to put in measures to protect malicious mysql injection attempts for sites developed this way?
A: The best measures against a malicious attacker exploiting a SQL Injection vulnerability is to prevent SQL Injection vulnerabilities in the first place.
And that means speicific coding patterns for the database interactions: prepared statements with bind placeholders. Or, at a minimum, properly escaping all potentially unsafe values that are included in the text of a SQL statement.
Your web page can have a drop down list box from which the user makes a choice, and your web page can do validation in Javascript. But that doesn't prevent a malicious attacker from bypassing that, and sending a request that doesn't conform the javascript validation.
The script on the server that handles the request will need to perform the validation... probably the same validation that was done in javascript on the web page that generated the request.
But any database interactions will also need to follow the normal patterns that prevent SQL Injection vulnerabilities (i.e. prepared statements with bind placeholders, or at a minimum, properly escaping potentially unsafe values.)
Multiple lines of defense.
It's not at all clear what you've been reading.
As a starting point, I recommend you review the information available from the OWASP project.
https://www.owasp.org/index.php/SQL_Injection
This isn't the be-all-end-all, but it's a good overview. If you are in a hurry, you can look at the SQL Injection Prevention Cheat Sheet.
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.
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.
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
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)