... I have a fairly large code base that I wrote before I became concerned about security issues. In this code base, there are plenty of places where I capture regexp groups on user inputs for reasons that have nothing to do whatsover with [validation].
You have code written without concern for security. The main body of this code operates freely on input, including using regexes. The code must now be re-written to take security into account. Given the nature of the code that I infer from your description, there is no way to avoid a major re-write of some kind.
Speaking in the most general terms, it seems to me that some new layer of validation code must be interposed between all input and existing operations on that input. Within that layer, input must be tested (presumably with regexes), and then either implicitly or explicitly untainted. If any input is allowed to reach the existing processing code, you have a security problem. The hermeticity of the new validation layer is the main problem; it seems to make little difference if the untainting done within it is implicit or explicit.
Update: I just went back and reviewed this thread and saw BrowserUk's reply. I seem to be repeating many of the points made therein, and I don't disagree with those I don't repeat. I sympathize with your desire for a mechanism that when activated would 'light up' the application for any input data not explicitly untainted, but that would not address the basic problem, common to both the current taint mechanism and the one you propose, of designing an effective test for each datum within a newly-designed validation layer. Caveat Programmor.
In reply to Re^5: Taint mode limitations
by AnomalousMonk
in thread Taint mode limitations
by alain_desilets
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |