Контроль доступа: защита базы данных

Мы запустили сканирование Fortify и столкнулись с некоторыми проблемами контроля доступа: базы данных. Код получает значение текстового поля и устанавливает его в строковую переменную. В этом случае он передает значение из TextBox хранимой процедуре в базе данных. Любые идеи о том, как я могу обойти эту проблему контроля доступа: база данных?

Без надлежащего контроля доступа метод ExecuteNonQuery() в DataBase.cs может выполнить инструкцию SQL в строке 320, содержащую первичный ключ, контролируемый злоумышленником, что позволит злоумышленнику получить доступ к несанкционированным записям.

Источник: Tool.ascx.cs:591 System.Web.UI.WebControls.TextBox.get_Text()

rptItem.FindControl("lblClmInvalidEntry").Visible = false;    
ToolDataAccess.UpdateToolData(strSDN, strSSNum, strRANC, strAdvRecDate, strAdvSubDate,  strClmRecDate, strClmAuth, strClmSubDate, strAdvAuth, txtNoteEntry.Text);

Приемник: DataBase.cs:278


System.Data.SqlClient.SqlParameterCollection.Add()
// Add parameters
foreach (SqlParameter parameter in parameters)
cmd.Parameters.Add(parameter);


fortify
person dotNetUser    schedule 30.12.2013    source источник

Ответы (1)


arrow_upward
8
arrow_downward

Пункт «Контроль доступа: база данных» заключается в том, что он недостаточно конкретен в запросе и поэтому потенциально может позволить пользователю видеть информацию, которую он не должен видеть. Простым примером этой уязвимости может быть база данных платежной ведомости, где есть текстовое поле, в котором указан идентификатор сотрудника и указана его зарплата. Это потенциально может позволить пользователю изменить идентификатор и увидеть зарплату других сотрудников. Другой пример, когда эта функция часто является предполагаемой, — это URL-адрес веб-сайта, где идентификатор продукта используется в параметре, что означает, что пользователь может просмотреть каждый продукт, который есть на вашем сайте. Но поскольку это позволяет пользователям видеть только ту информацию, которую они должны видеть, это не является особой проблемой безопасности.

Например:

"SELECT account_balance FROM accounts WHERE account_number = " + $input_from_attacker + ";"
// even if we safely build the query above, preventing change to the query structure,
// the attacker can still send someone else's account number, and read Grandma's balance!

Поскольку это в значительной степени зависит от контекста, его трудно определить статически, поэтому существует множество примеров, когда Fortify может уловить это, но на самом деле это предполагаемая функциональность. Это не значит, что инструмент неисправен, это просто одно из ограничений статического анализа, и в зависимости от того, что должна делать ваша программа, он может быть предназначен или не предназначен. Если это предназначено для такой работы, то я бы предложил проверить это как не проблему или подавить проблему. Если вы видите, что это определенно проблема, и пользователи могут видеть информацию, которую они не должны видеть, тогда хранимая процедура должна быть более конкретной, чтобы пользователи могли видеть только ту информацию, которую они должны видеть. Однако SCA, скорее всего, обнаружит это при последнем сканировании, поэтому вам все равно придется проверять его как исправленное и больше не являющееся проблемой.

person lavamunky    schedule 07.01.2014
comment
Любое решение для обхода в mybatis - person Ben Cheng; 02.01.2019