Welcome Guest, Not a member yet? Register   Sign In
$this->input->post(), raw data?
#1

[eluser]Michael;[/eluser]
I'm working on an implementation of a "pastebin" and have run into a bit of a problem. Is there any way to *SAFELY* get raw code into and out of the database for display, without losing any of the code?

I started testing with the hackers cheat sheet and certain tags end up as "removed" in the code. Obviously this is done for security purposes, but for obvious reasons there are legitimate purposes in which you really do want the code to be displayed as it is.

Obviously I'm not hold out much hope that this is really possible to do safely, but I thought I would ask anyway.
#2

[eluser]Popcorn[/eluser]
I think you can still use the POST array, but I can't remember if CodeIgniter kills it or not. If you need a custom security measure I think it would benefit you to write your own queries instead of using the Active Record functionality(I assume you are).
#3

[eluser]Michael Wales[/eluser]
I was writing a pastie at one time as well - I found the best solution was to turn off global XSS cleaning and implement my own security procedures within the Form Validation library (well, an extension of that).
#4

[eluser]Michael;[/eluser]
Hmmm... I'm not so sure that is a risk I'm willing to take. There are some evil people out there that will take advantage of any little inch you give them.

I dunno ... tough call.
#5

[eluser]Phil Sturgeon[/eluser]
Whack htmlspecialchars and addslashes on the raw $_POST and I cant see them getting too far. Again, do that yourself and not with AR.
#6

[eluser]Michael;[/eluser]
You know, that's what i would have thought too ... but with the global xss_clean() running it rips apart $_POST too.

CI is great on security ... I'll give it that hands down. Smile
#7

[eluser]Michael;[/eluser]
Okay... I thought this horse would use another round of whippings.

Query: I know it's possible to programically turn off xss_clean() by merely setting the config item to FALSE; say in the pastie controller's construct ... But, here's the rub; with the $config['xss_clean'] = TRUE in the config file, when does it automagically turn itself back on?

Here's what I was thinking ... turn xss_clean() off in the construct, go about the pastie, then use the encryption class to encrypt $this->input->post ( thus rendering any malicious XSS completely harmless ) and store the encrypted item in the database, and decrypt just before display.

So far the only "sticking" point is the global xss_clean(). It sanitizes $this->input->post() before I can encrypt it, so I'm wondering how long it'll take for the global to turn itself back ... or if it will at all.

Thanks,
Michael
#8

[eluser]Pascal Kriete[/eluser]
The global sanitation happens in the Input library constructor, which actually runs quite a while before the controller is instantiated.

The only spot where you could modify this particular config setting is in the cache_override hook. Doing that would make the code very hard to maintain in the future though (cache_override is not where you would expect a setting like this to be).

Your best bet is probably to just keep it off globally. You can always call the security helper or input class when you need to clean input.

As for encrypting before inserting - no need. XSS is a client side attack, it cannot hurt your database. SQL injection can, but if you're using active record or query bindings, CI has you covered and will escape the input properly.

Bottom line, just be mindful of the possibilities and scrub, scrub, scrub the data you display! As pyro suggested, converting html entities is a definite must.
#9

[eluser]Michael;[/eluser]
Well, by no means will I claim that security is my particular brand of pain; it's one of the primary reasons I prefer the use of frameworks and CMSes with a solid API andthe hooks to build upon.

However, in terms of CI, and keeping an application secure: I do not use active record, but I *DO* use query bindings on *EVERY* query I write for any application ... so i think I'm safe in terms of SQL injection; but is running xss_Clean() as a rule on form field enough to keep an application secure when turning off the global setting? I use sessions in conjunction with a database table so typically I don't use cookie data, but if I were I would assume that I would need to run xss_clean() on anything coming from a cookie if I were to need to use one (like for a login 'remember me' feature).

So, security checklist:

Query bindings: Check
xss_clean() as a rule on all form fields: Check
Xss_clean() any cookie data before use: Check

Is that all there is to it?

Thanks,
Michael;
#10

[eluser]Unknown[/eluser]
The only spot where you could modify this particular config setting is in the cache_override hook. Doing that would make the code very hard to maintain in the future though (cache_override is not where you would expect a setting like this to be).

Your best bet is probably to just keep it off globally. You can always call the security helper or input class when you need to clean input.




Theme © iAndrew 2016 - Forum software by © MyBB