Расширение Безопасности с точки зрения типов, чтобы препятствовать тому, чтобы грязные данные прибыли использоваться против функций, которые требуют “чистых” [закрытых] данных

Может ли .NET или один из его множества языков принудительно очищать ненадежные данные

Да, может, но не так, как вы спрашиваете. Вместо этого вы гарантируете чистый sql, правильно параметризовав его. Например:

string sql = "SELECT * FROM [table] WHERE [column] = @value";
using (var cn = new SqlConnection("connection string here"))
using (var cmd = new SqlCommand(sql, cn)
{
    cmd.Parameters.Add("@value").Value = "'';DROP Table Users;--";
    cn.Open();
    SomeControl.DataSource = cmd.ExecuteReader();
    SomeControl.DataBind();
}

Этот код совершенно безопасно запускать, даже если есть очевидная попытка внедрения. Причина в том, что набор параметров объекта SqlCommand не никогда не заменяется непосредственно в запросе. Данные отправляются на сервер и обрабатываются полностью отдельно от кода, поэтому все в безопасности, независимо от того, что вводит пользователь.

Все, что вы делаете, чтобы «очистить» запрос, всегда будет гонкой вооружений с взломщиками. Таким образом, правильно хранятся данные и код отдельно.

Похоже, вы предполагаете, что может быть только один способ sanitize () данных. Проблема в том, что уязвимость сильно зависит от того, как используются данные, и поэтому на практике этот подход очень сложен. Например, у sql-инъекций и xss очень мало общего, и они никогда не должны использовать одну и ту же функцию. Фактически, есть очень мало сходств между какими-либо недостатками впрыска .

При этом лучшая реализация Проверки заражения - это безопасный режим ruby ​​. IronRuby позволяет использовать Ruby в .net. Это работает за счет наличия списка функций очистки, которые помечают переменную как чистую. Но даже это не остановит все: если вы посмотрите на owasp top 10 , то только уязвимости A1-Injection и A2-XSS вызваны испорченным вводом, остальные - нет, особенно CSRF.