This is becomming a very very interesting discussion !
Here's my point : if you only autohrize "abcdefghijklmnopqrsquvwxyz" +
'0123456789' + ".,;:()/[] '
I'm pretty sure there's no way to make an attack, xss or sql injection.
- You can't make a sql injection because you need "\" to do this and if you
escape all user input (" and ') you're ok- You can't make a xss because you
need < and > to do it.
So, ok you loose a lot of possibilities (like you can't allow html), but I can
live with that.
Now doing so I'm just applying one very basic principle of security : remove
everything you don't absolutely need.
What I miss is *how* to build such a function that would filter all these
chars. And I'd love a little help on this side ;-)
Z.PS : I don't say you can't use htmlpurifyer as one more layer of protection
with this policy ;-)
--
My dojo & zend framework experience, the good, the bad with code samples ;-)
http://practicalphpajax.wordpress.com/
> Date: Tue, 1 Mar 2011 20:09:00 -0500
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> Subject: Re: [fw-general] Zend guru advise on how to build a secure function
>
> Hey Zladivliba,
>
> > I'd like to use a SecureText function that filters any "potential risky"
> > text input from my website.
>
> This "function" depends on which risk you wish to prevent.
>
> > So what's "potential risky text" for me : everything that's not : a-zA-Z0-9
> > ;.,?+-_![]/()This clears any hack potential from XSS or SQL injection. This
> > limits the usability of my website, but I don't care, as long as xss are not
> > possible any more, and sql injections are out of the way it's perfectly
> > viable
> > for what I want to do and the needs of my users.
>
> If you want to create something that would be an escape sequence for both HTML
> and SQL, you'll have a really difficult time in attempting a feat like this.
> The
> best practices to avoid any XSS, XSRF, SQL Injection, or any other kind of
> exploit would be to *VALIDATE* your input as you receive it from the user, and
> *ESCAPE* all output to any stream.
>
> What I mean by validating input: Make sure the data you are receiving from the
> user is the type of data you would expect. For example, if you are expecting a
> date pattern, then validate against a date pattern. If you are expecting an
> alpha-numeric string, then validate against this.
>
> What I mean by escaping all output is to ensure data is escaped properly
> according to the rules of the stream to which you are writing. Writing up
> something that is supposed to escape output as it goes to SQL, XML/HTML, CSS
> and/or JS would be extremely tedious, not to mention you would probably be
> limited to a set of word characters, with nothing special in between. This is
> due to the numerous rules that are in place that define the characters which
> are
> special to each language.
>
> A good practice would be to escape your data to the appropriate stream. For
> example, if you are writing up a MySQL query, use prepared statements and bind
> your input to variables to ensure the data is properly escaped before
> performing
> the query. PDO<http://php.net/pdo> and MySQLi<http://php.net/mysqli> are very
> good at this. Aside from this point, Zend_Db and it's database adapters do
> well
> to bind parameters to prepared statements, which abstracts you from the
> database
> enough to not have to worry about this. If you must use a raw query to the
> database, http://php.net/mysql_real_escape_string will be your best friend in
> this instance.
>
> When spitting data out to the browser, use $this->escape($data) in your views
> and partials to ensure the data is escaped according to the rules of HTML. By
> default $this->escape uses http://php.net/htmlEntities, which can be changed
> quite easily to something else, should you need to escape for XML data.
> As for JavaScript, use Zend_Json::encode() and Zend_Json::decode() to pass
> data
> to and from the client/server to manipulate data that should be passed to
> JavaScript.
>
> A great blog I follow by this security officer, Mike Baily:
> http://blog.skeptikal.org/
> A lot of what I know and am preaching comes from him (not necessarily
> ZF-related, but generic security related).
>
> > Now the question is how to build such a function. It seems that I can't use
> > preg_replace because of unicode characters.I've tried to use filter_var but
> > I'm
> > not sure it filters also unicode characters. And I really want to strip
> > everything that's risky it's my main priority.
> > Cool guys on #Zftalk have advised to use pregReplace filter build in ZF
> > since I
> > have a regexp, but I'm not sure regexp is secure so...
> > Any help appreciated ! I'm a little lost with this.
>
> To build a single function would not be plausible, as stated above. It would
> take a collection of functions to ensure this is done properly. I once
> created a
> function long ago that was supposed to do this magic "filter and escape all."
> However, I have since learned that such a function is not good practice
> because
> you then end up with the wrong type of escape sequences for different types of
> data.
> http://pastie.org/941165
> You may use this function, if you wish, however I advise against it for the
> reasons stated in the above paragraph.
>
> Using RegEx's to filter your data can be helpful, but I don't recommend it as
> a
> "one size fit's all" scenario. There are still ways of bypassing the RegEx
> filters. For example, if you allow the "e" modifier in your regular
> expressions
> and use user-input for the replace pattern, that's a recipe for disaster.
> http://www.murraypicton.com/2010/11/using-phps-preg_replace-with-the-e-modifier/
>
> That's not to say that RegEx's are bad, but it should give a little wind of
> caution against the 'e' modifier in RegEx's. Though, RegEx's are good for
> validating against specific sets of data, such as phone numbers, eMail
> addresses, and other specific types of strings.
>
>
> One last bit of advice: If you are looking for something that will be 100%
> secure, you will be searching for a very, very long time. The philosophy I've
> learned in the realm of Information Security is that you can NEVER had
> anything
> that is absolutely secure in every single manner. It's much easier to try and
> hack/break something than it is to protect against exploit. There is no such
> thing as something that is totally secure, as someone will always attempt to
> bruteforce their way into the application until they've accomplished their
> goal
> (given they've the time :P). You can only implement ways of protecting against
> that threat in the hopes that you will drive them away.
>
> Additionally, I second everybody's statement that you should not try to
> re-invent the wheel :)
>
> Hope this helps,
> -Kizano
> //-----
> Information Security
> eMail: [email protected]
> http://www.markizano.net/
