Welcome Guest, Not a member yet? Register   Sign In
Protection from SQL-injections and XSS-atacks
#1

I suppose codeigniter has built-in defense system, but how properly use it?
e.g. - we have user's input - Name, password, message?
Do i have to manually  call native php functions - 
strip_tags($_POST['name']);
htmlentities($_POST['name'], ENT_QUOTES, "UTF-8");
htmlspecialchars($_POST['name'], ENT_QUOTES);

Or CI - automatically checks that?

Can you explain everything in details, because - safety first☺
Reply
#2

And what about PDO? Is there need to configure CI to work only using PDO?
Reply
#3

(07-13-2017, 10:47 AM)glorsh66 Wrote: And what about PDO? Is there need to configure CI to work only using PDO?

For SQL Injection use CI's Active Record, this will handle sanitation of user input automatically, as for output it's impossible to know for sure whether an output should be sanitised or not automatically so you'll need to do that yourself when echo'ing variables in a view, CI does have some automatic protections in this regard though, e.g values for form inputs are sanitised automatically.
Reply
#4

Hmmm - ActiveRecord hasn't been a thing for several years now ... renamed the Query Builder in CI3.

It sounds like you might have overlooked the user guide section dealing with the problems you mention ... https://www.codeigniter.com/user_guide/l...urity.html
Reply
#5

(07-13-2017, 11:33 AM)ciadmin Wrote: Hmmm - ActiveRecord hasn't been a thing for several years now ... renamed the Query Builder in CI3.

It sounds like you might have overlooked the user guide section dealing with the problems you mention ... https://www.codeigniter.com/user_guide/l...urity.html

I have read this, it is not explicitly said - do i need - use htmlspecialchars, or not?


Quote:which looks for commonly used techniques to trigger JavaScript or other types of code that attempt to hijack cookies or do other malicious things.
But what does it lack? What additional security measures must be done?
Reply
#6

(This post was last modified: 07-13-2017, 02:27 PM by PaulD. Edit Reason: Added PPS )

(07-13-2017, 10:41 AM)glorsh66 Wrote: Can you explain everything in details, because - safety first
No, because it is not a case of do A and do B and everything will be fine. Sometimes you need to do C, sometimes just A will do, and on occasion you might do D, E or F. It all depends on many factors.



(07-13-2017, 10:41 AM)glorsh66 Wrote: I suppose codeigniter has built-in defense system, but how properly use it?
The docs for security do explain this. Also, Form validation helps you validate input. The query builder helps protect you from sql injection automatically. CSRF helps protect against XSS attacks. Clean data function helps to remove unwanted or suspicious code etc. Security is much more than just cleaning output or validating input. Also, in truth, there is no single agreed upon method which works 100% of the time in all cases. Validate input, clean output. Even a Model takes input and provides output. Validate it, and clean it in whatever ways makes sense for your usage and purpose.

(07-13-2017, 10:41 AM)glorsh66 Wrote: e.g. - we have user's input - Name, password, message?
Do i have to manually  call native php functions - 
strip_tags($_POST['name']);
htmlentities($_POST['name'], ENT_QUOTES, "UTF-8");
htmlspecialchars($_POST['name'], ENT_QUOTES);
Unfortunately, it still depends. You should be validating input and cleaning output. It took me ages to get my head around this too as it seems obvious to clean on input, but actually it is not.

(07-13-2017, 10:41 AM)glorsh66 Wrote: Or CI - automatically checks that?
No, definitely not. But you can, if you choose, use the optional second parameter in the input function to xss_clean your input like this:
PHP Code:
$this->input->post('username'TRUE); 
But I do not do this very often any more.

For your views, for user generated input, to prevent breaking html, you should still use html_entities() where appropriate to do so or html_specialchars. Except of course when you specifically do not want to do that.

Hope that helps,

Paul.

PS. It all seems a bit of a nightmare at first, but when you get into the swing of doing it, you do it without really thinking about it.

PPS. As a first step, try breaking your own site. What happens to your fields when you try to insert corrupting data? Does it fail gracefully, does it catch the offending input etc. Then perhaps run a few of the automated security checking apps that are around. See what they say about your site.
Reply
#7

Beyond the form validation that CI provides, you can also use your own custom validation rules, and you should if you have to. Also, I like to type cast numbers to int or float, sometimes eliminating the need for form validation if all I'm posting is numbers. While it is specifically suggested that it not be done, I do run almost almost all strings through xss_clean. If that's just a bad habit, and if somebody wants to share an article to read about why it is so, I might be persuaded to change my ways.
Reply
#8

(07-13-2017, 02:23 PM)PaulD Wrote: CSRF helps protect against XSS attacks.

Um, no ... CSRF doesn't protect you from XSS. It's the name of another attack, which CI has protections against.

(07-13-2017, 11:47 PM)skunkbad Wrote: Also, I like to type cast numbers to int or float, sometimes eliminating the need for form validation if all I'm posting is numbers.

You should avoid this ... It may be an easy way to protect from SQL injections, but you're supposed to reject invalid inputs, not assume that they're ok.
Reply
#9

(This post was last modified: 07-14-2017, 10:59 AM by skunkbad.)

(07-14-2017, 02:43 AM)Narf Wrote:
(07-13-2017, 11:47 PM)skunkbad Wrote: Also, I like to type cast numbers to int or float, sometimes eliminating the need for form validation if all I'm posting is numbers.

You should avoid this ... It may be an easy way to protect from SQL injections, but you're supposed to reject invalid inputs, not assume that they're ok.

I wouldn't usually assume the type casted value is OK. It really depends on what I'm doing. I guess I was rather vague when suggesting that form validation may not be necessary. Something like this is probably OK for an integer that is not 0:


PHP Code:
$val $this->input->post('x');
if( 
is_numeric$val ) ){
   if( $val = (int) $val ){
       // $val is safe
      return $val;
   }



To be clear, I'm certainly not telling you what's OK ... because you are much more advanced than I am. Would you always use the form validation class, or how would you otherwise handle this?
Reply
#10

(07-14-2017, 10:58 AM)skunkbad Wrote:
(07-14-2017, 02:43 AM)Narf Wrote:
(07-13-2017, 11:47 PM)skunkbad Wrote: Also, I like to type cast numbers to int or float, sometimes eliminating the need for form validation if all I'm posting is numbers.

You should avoid this ... It may be an easy way to protect from SQL injections, but you're supposed to reject invalid inputs, not assume that they're ok.

I wouldn't usually assume the type casted value is OK. It really depends on what I'm doing. I guess I was rather vague when suggesting that form validation may not be necessary. Something like this is probably OK for an integer that is not 0:


PHP Code:
$val $this->input->post('x');
if( 
is_numeric$val ) ){
   if( $val = (int) $val ){
       // $val is safe
      return $val;
   }



To be clear, I'm certainly not telling you what's OK ... because you are much more advanced than I am. Would you always use the form validation class, or how would you otherwise handle this?

I'm not a big fan of FV libraries in general, but ultimately it's a choice. Otherwise I'd use ctype_digit() instead of is_numeric().

But the point is that you need to know that the input was correct before doing anything with it. Casting after validation is fine ... relying on casting instead of validation isn't. Smile
Reply




Theme © iAndrew 2016 - Forum software by © MyBB