Implement Data Tainting in the CLR
Managed code derives considerable security advantages from having a verifiable memory model, but does not directly address the issue of unsanitised input data. Yet this is the root cause of the most common classes of security vulnerabilities seen today: SQLi and XSS, and is a contributing factor in almost all of them.
At the most trivial level, taint checking is just an extra bit that needs tracking for every object in memory, and combining and propagating though operands. Guarding against unsafe input data on security-critical paths (eg using code contracts) it could completely eliminate entire categories of attack vector. This would go far beyond the targeted safeguards which ASP.Net MVC currently implements and give the safety (or otherwise) of data system-wide visibility, to be checked for or asserted against as required.
Taking it one step further, if all user-input functions were appropriately tagged, taint checking could become a static analysis function, where vulnerable code pathways could be flagged (or rejected) at compile time.
Wikipedia on taint checking: http://en.wikipedia.org/wiki/Taint_checking
Thank you for your suggestion! While we aim to respond to every suggestion, we are closing older ones that don’t have enough votes so newer ones from you can move to the top. If this suggestion is still important to you, feel free to open it again.
Piers Williams commented
I wrote a longer essay on my blog about why I think this is a good idea: http://piers7.blogspot.com.au/2014/04/its-time-to-bring-data-tainting-to-clr.html