views:

52

answers:

3

Some doubts regarding Codeigniter and its Input handling capabilities. Some may be a little weird but they are doubts none-the-less.

  1. If I use the Active Record Class functions in CodeIgniter, is my input prevented against SQL injection?
  2. I read somewhere that it does, but I don't understand it how? or why?
  3. Also does xssclean deal with SQL injection in any way?
A: 

Whenver you use User Generated Input then pass it through the input library where it filters for xss and sql injections.

$this->input->post() 

http://codeigniter.com/user_guide/libraries/input.html

Do check for more info on security filtering.

Within the CI framework check the file

Codeigniter->System-libraries-> input.php

file where you can find internally the functions used by CI for sanitizing data.

XSS clean basically means filtering Out unwanted XHTML/HTML Tags

Sandy
+1  A: 

1. it does if you do it properly

2. You will probably have noticed that all function calls are in a way that user data is passed in one variable each. So you don't even have the possibility to pass SQL controll code and user data in one variable. Speaking short, data is encapsulated in one variable each. Therefore it can be safely encoded without breaking your SQL code. The exception is however if you pass yóur whole query. Then its not possible. If you do

$db->query("select * from table where password = 'hello ' or '1=1");

there is no way of telling what should be escaped and whats not but if you quote it in like this

$db->query("select * from table where password = ?",array('param1'));

the user variable gets encapsulated in one variable and will be escaped.

3. Yes it does but its primpary purpose is not to prevent sql injection, i would rather rely on http://codeigniter.com/user_guide/libraries/input.html

Joe Hopfgartner
I think there shouldn't be single quotes around the `?` parameter here.
bobince
hmm... can't really say. i think its correct that way. of course you don't need it when you have integers, but it doesnt really matter... so its probably better to write it like so?
Joe Hopfgartner
Well, I haven't tried this with CodeIgniter specifically, but by far the most common way of doing parameterised queries is to use a bare `?` as a replacement point, and treat `'?'` in a string as an actual question mark. This seems to be the syntax given at http://codeigniter.com/user_guide/database/queries.html, anyhow.
bobince
you're totally right on this one :) +1
Joe Hopfgartner
+2  A: 

is my input prevented against SQL injection?

Not exactly ‘automatically’, but it does provide parameterised queries. CodeIgniter or no, you should use parameterised queries in preference to query string hacking whenever possible.

$bof= "a'b";
$zot= 'a\b';

// Insecure! Don't do this!
//
$this->db->query("SELECT foo FROM bar WHERE bof='$bof' AND zot='$zot'"); 

// Secure but annoying to write
//
$this->db->query("SELECT foo FROM bar WHERE bof='".$this->db->escape($bof)."' AND zot='".$this->db->escape($zot)."'"); 

// This is what you want
//
$this->db->query('SELECT foo FROM bar WHERE bof=? AND zot=?', array($bof, $zot)); 

Note this is nothing to do with ‘input’: when you make an SQL query from strings you must use parameterisation or escaping to make them fit, regardless of whether they're user input or not. This is a matter of simple correctness; security is a side-effect of that correctness.

Similarly when you output text into HTML, you need to HTML-encode <, & and " characters in it then. It is absolutely no use trying to fiddle with the input to escape or remove characters that might be troublesome in the future if you happen to use them without escaping in SQL or HTML. You'll mangle your output by having unexpected SQL-escaping in HTML (which is why you see self-multiplying backslashes in badly-written apps) and unwanted HTML-escaping in SQL. And should you take text from somewhere other than that direct user input (say, material already in the database) you aren't protected at all.

Also does xssclean deal with SQL injection in any way?

No. It's aimed at HTML injection. But it's worse than worthless. Never use it.

“XSS filtering” is completely bogus (again, CodeIgniter's or anyone else's). XSS needs to be prevented by correctly HTML-escaping output, not mangling input. XSS filtering will not adequately protect you if your application is not already secure; at best it will obfuscate your existing flaws and give you a false sense of security. It will also mangle a lot of valid input that CI thinks looks like tags.

bobince
Interesting! The last point especially. I think your way is really better.
OrangeRind
Care to explain why CI's xssclean is worthless? I'm seriously curious! It's half the reason I use CI. I'd like to know if I'm deluding myself and not secure!
kevtrout
If you're remembering to HTML-escape all strings you output into your HTML pages, you're secure whether or not you use `xss_clean`, and all it will be doing for you is quietly mangling your input strings, in frighteningly bizarre ways. Seriously, have a look at `function xss_clean` in `Input.php` and laugh as it replaces things with `%` in, URL-decodes, replaces things with `%` in again, breaks URL-encoded links, mangles words with ampersands between them, escapes *some* less-than signs to `<`, and prevents you from talking about `innerHTML` or using the word `alert`... and more...
bobince
Basically, it's cargo-cult programming. The authors don't understand a thing about how HTML-encoding and URL-encoding work, so they throw everything they've got at it randomly in the hope that something will stick. It would be hilarious if it wasn't so sad. And it can't ever work. Even if it did work for strings on their own, all it would take would be a big of string-handling in the script afterwards—say, a split and join with another supposedly ‘safe’ string—to make it dangerous again.
bobince
It looks like they've had this filter in there and every so often someone comes up with an exploit that gets round it, at which point they throw more spurious rubbish in to target that one exploit, without tackling the real problem. Blocking `alert` is symptomatic as it's a JS function that you typically use to *demonstrate* that an XSS vulnerability *exists*; no *real* exploit of that vulnerability would ever actually pop up an alert box! And the multiple ways, all different they try to parse HTML looking for “bad” tags... jeez.
bobince
Even if all this absurd, baroque maze of broken regexes actually worked, it still wouldn't be enough, because it's acting on user input and not HTML output. If output comes from something other than form input (eg. untreated or post-processed or truncated database data, or other sources), you're still spitting out unsafe HTML. The *only* way to prevent XSS is HTML-escaping output; escaping or stripping the input is bad, and the way CodeIgniter does it is laughably bad even beyond the standards of beginners' PHP apps. It is some of the most insane, misguided code I have ever witnessed.
bobince
phew! ;) That was one big comment!
OrangeRind
yeah, sorry about that. Looking at the code again made me cross.
bobince