Re: Untainting safely. (b0iler proofing?)

I think what merlyn and fastolfe are getting at is not all the data parsed to your cgi (tm) requires untainting.

For example if you accept a $q->param and send it back to the browser as a "Hello world" example, save for a 20Mb input, why would you need to untaint it?

If on the other hand, if you are calling the shell, you need to check for naughty characters.

So untainting your data depends completly on the context in which your application is developed.

I think you *may* be getting confused between untainting and data validation. There is a difference, the former making sure there are no naughty characters in your input, the later checking the data conforms to a standard.

Anyway's FWIW, i think a centralised method of data validation would be cool, however i dont think untainting can really be centralised outside of the context of the application for which its developed.

Comment on Re: Untainting safely. (b0iler proofing?)

Replies are listed 'Best First'.
Re: Re: Untainting safely. (b0iler proofing?) by BrowserUk (Patriarch) on Jun 26, 2002 at 20:36 UTC
Respectfully, I thought that your "Hello world" example, or more classically, the "Hello Ryzard, welcome back" using your name supplied from a form was benign until I read this - but when you see that by embedding HTML and script tags into the name field can, when returned to the browser for display, open up a wealth of possibilities of cross-site scripting and cookie theft, it made me think again. Beleive me, I am not mixing data validation and untainting up. Data validation is very much an application specific function. An telephone number or zip code validation routine written for US numbers/ZIP's would have no application here in the UK. However, sanitising almost any external input has universal application. the same hacks and cracks that would affect your server will (in most cases) affect my server too. As I wrote elsewhere, there are very few uses of external data that are cause for concern - opens, commands, database entry, re-display, passing to other modules - very few more. The hacks that are possible in each of these cases are limited and the fixes/preventions should be pretty much the same wherever the program is destined to run. Its also much harder, and requires much greater experience to prevent the "Reverse Directory Transversal" vuln than it is to validate a date or a ZIP or telephone number. The latter is a fairly standard programming problem. The former, as bugtraq prooves, is a much harder and requires much greater real world expertise. Hence my beleif that it is a ripe candidate for standardisation. However, it seems that I am in a minority and/or 'nih' syndrome is at play here :(	[reply]

Replies are listed 'Best First'.

Re: Re: Untainting safely. (b0iler proofing?)
by BrowserUk (Patriarch) on Jun 26, 2002 at 20:36 UTC

Respectfully, I thought that your "Hello world" example, or more classically, the "Hello Ryzard, welcome back" using your name supplied from a form was benign until I read this - but when you see that by embedding HTML and script tags into the name field can, when returned to the browser for display, open up a wealth of possibilities of cross-site scripting and cookie theft, it made me think again.

Beleive me, I am not mixing data validation and untainting up. Data validation is very much an application specific function. An telephone number or zip code validation routine written for US numbers/ZIP's would have no application here in the UK.

However, sanitising almost any external input has universal application. the same hacks and cracks that would affect your server will (in most cases) affect my server too.

As I wrote elsewhere, there are very few uses of external data that are cause for concern - opens, commands, database entry, re-display, passing to other modules - very few more. The hacks that are possible in each of these cases are limited and the fixes/preventions should be pretty much the same wherever the program is destined to run. Its also much harder, and requires much greater experience to prevent the "Reverse Directory Transversal" vuln than it is to validate a date or a ZIP or telephone number.

The latter is a fairly standard programming problem.

The former, as bugtraq prooves, is a much harder and requires much greater real world expertise.

Hence my beleif that it is a ripe candidate for standardisation.

However, it seems that I am in a minority and/or 'nih' syndrome is at play here :(

[reply]