zit-hb
commented
2 years ago Hello,
I think it is a good idea. When I designed the architecture I did not add a blacklist scan of parameter names because the whitelist will block unknown parameter names. In reality, many people only use the blacklist but not the whitelist due to much higher maintenance efforts. Thus, scanning the parameter name with the blacklist would add additional value.
It might actually be not very difficult to add this. A possibility would be to add an additional check here. I will have to test it but I am pretty sure that would work. The only down side I see with this approach is that it would not be very clear in the UI if the blacklist removed a parameter because of its name or its value. On the other hand I do not think that this will happen very often anyway, so it might be acceptable. I will test it out in about 2 weeks.
keramahos
Hey. I really like shadowd approach to this problem and I'd like to give it a go into production, but I need this enhancement to be implemented as this is pretty crucial in our type of business.
The problem: This is rule (path): GET|\bselect\b.+?\bfrom\b URL scanned by shadowd: new_api.php?id=select%20%20from%20a%20where%201=1 become blocked. URL scanned by shadowd: new_api/?select%20%20from%20a%20where%201=1 pass through.
Main goal is to scan whole URL and block everything what matches the rule (path) because some URL rewrites is going directly to backend and should be blocked as malicious.
Many thanks.