http://www.perlmonks.org?node_id=1002213


in reply to Re^6: Taint mode limitations
in thread Taint mode limitations

But everything else should be caught by taint mode (and I can’t see a technical reason why it can’t be done).

I can only ask you to re-read what I wrote in the last section of Re^3: Taint mode limitations.

I do not disagree that taint mode could have been implemented in a manner that would make it more amenable to being used to catch and fix-up poor code. But it wasn't.

Alain is now faced with a problem of fixing up his -- self-described -- poor code. Petitioning for a change to the implementation at this point is most unlikely to help him. Even if everyone agreed a change would be beneficial, it would likely be a long time before that made it into a new release.

And given the existing mechanism is used my millions of pieces of code out there in the real world; and there is no real way to make his explicit de-tainting mechanism co-exist with the current mechanism; the likelyhood of it ever being implemented is very low.

That leaves Alain one obvious choice.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

Replies are listed 'Best First'.
Re^8: Taint mode limitations
by Anonymous Monk on Nov 04, 2012 at 16:33 UTC
    Alain is now faced with a problem of fixing up his -- self-described -- poor code.

    I never said that the code is poor. It just wasn't written with security in mind. But it is very well designed and modular, and it will be almost trivial to add a user input sanitization layer to it (see: http://www.perlmonks.org/?node_id=1002211)

    This layer will protect my app against malicious user input, to the full extent of what is possible given the current limitations of taint mode. But it will still leave many possibilities for error which would be caught if the features I suggest were added to taint mode.

    And given the existing mechanism is used my millions of pieces of code out there in the real world; and there is no real way to make his explicit de-tainting mechanism co-exist with the current mechanism; the likelyhood of it ever being implemented is very low.

    I may be wrong, but I think the taint mode enhancements I propose are completely compatible with the current taint mode. All that is needed is to add an extra option to specify how lenient you want taint mode to be. The default should of course to let it be as lenient as it is now. But those of us who aren't happy with its current leniency could specify a different value for that option.