neuroo
commented
11 years ago We thought about that, but I'm not sure it's the right approach (as a main API). I have no problem exposing such API though if you feel like there is a need. Few things to consider:
- There is a need to get the list of contexts right (which is not obvious sometimes)
- The remediation engine wouldn't spit out this version first (unless we believe it's best to do so), so it's less obvious for developers to use this API.
- Also, I'm not sure the number of contexts will grow significantly to suggest such change. From the analysis we did, we might see up to 4 nested contexts (did we ever see or come up with a 5??), but that's it.
Thing to consider: this approach also makes sense when the remediation is only to be applied at one place (most likely injection site). When we start adding filters, validators, etc. it then becomes more complex to use a unified API like that.
Anyways, I really have not much opinion on whether or not we should have this available... I guess I just don't see much interest for now. Do you have strong feelings for it?
jpasski
As the library grows I think we'll start to have a lot of different escapers and subsequently, different method names and tag libraries. This may get confusing and also creates large nesting of methods. E.g. escaperA(escaperB(escaperC(tainted_data))). As an option I'm proposing adding a generic escaping name with a second field (first field is still the input string) that takes a List of Context enums. This would allow the author to declare the intent more succinctly to me. The underlying implementation would then just iterate over the list, calling the respective escaper method. While this adds some overhead, I think there's a benefit for some people.