Как исправить массовое назначение: небезопасная конфигурация Binder (API Abuse, Structural) в Java

Question

У меня есть класс Controller с двумя приведенными ниже методами поиска врачей (контекст изменился). Получение массового назначения: ошибка небезопасной конфигурации связующего (API Abuse, Structural) в обоих методах.

@Controller
@RequestMapping(value = "/findDocSearch")
public class Controller {

    @Autowired
    private IFindDocService findDocService;

    @RequestMapping(value = "/byName", method = RequestMethod.GET)
    @ResponseBody
    public List<FindDocDTO> findDocByName(FindDocBean bean) {
        return findDocService.retrieveDocByName(bean.getName());
    }

    @RequestMapping(value = "/byLoc", method = RequestMethod.GET)
    @ResponseBody
    public List<FindDocDTO> findDocByLocation(FindDocBean bean) {
        return findDocService.retrieveDocByZipCode(bean.getZipcode(),
        bean.getDistance());
    }
}

и мой боб:

public class FindDocBean implements Serializable {
    private static final long serialVersionUID = -1212xxxL;

    private String name;
    private String zipcode;
    private int distance;

    @Override
    public String toString() {
        return String.format("FindDocBean[name: %s, zipcode:%s, distance:%s]",
                name, zipcode, distance);
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getZipcode() {
        return zipcode;
    }

    public void setZipcode(String zipcode) {
        this.zipcode = zipcode;
    }

    public int getDistance() {
        return distance;
    }

    public void setDistance(int distance) {
        this.distance = distance;
    }

Согласно всем предложениям, найденным до сих пор, они предлагают ограничить бин требуемыми параметрами только чем-то вроде ниже:

final String[] DISALLOWED_FIELDS = new String[]{"bean.name", "bean.zipcode", };

@InitBinder
public void initBinder(WebDataBinder binder) {
    binder.setDisallowedFields(DISALLOWED_FIELDS);

Но моя проблема в том, что все 3 параметра компонента будут использоваться в любом из методов, предоставляемых на контроллере.

Может кто-нибудь, пожалуйста, предложить какое-то решение для этого. Заранее спасибо.

Answer 1

InitBinder может быть использован для методов. Вы можете попробовать это.

@InitBinder("findDocByName")
public void initBinderByName(WebDataBinder binder) {
    binder.setDisallowedFields(new String[]{"distance","zipcode"});
}


@InitBinder("findDocByLocation")
public void initBinderByZipCode(WebDataBinder binder) {
    binder.setDisallowedFields(new String[]{"distance","name"});
}

Answer 2

Я столкнулся с той же проблемой, затем я добавил ниже код в том же классе контроллера остальных:

@InitBinder
public void populateCustomerRequest(WebDataBinder binder) {
    binder.setDisallowedFields(new String[]{});
}

Теперь он работает нормально для меня, и проблема массовых назначений была исправлена.

Answer 3

Если кто-то сталкивается с этой проблемой в C# .net core API, добавьте в контроллер [Bind] или [Bind("prop1","prop2")] вместо [FromBody].

Добавление этого решения здесь, потому что нигде не может найти подходящего решения для c # webapi. Это может быть полезно для кого-то в функции

ссылка - https://softdevpractice.com/blog/asp-net-core-how-to-prevent-mass-assignment-attacks/

Answer 4

Это выглядит как неудачный ложный позитив. Правило, лежащее в основе этой ошибки, сделано для того, чтобы избежать случайного заполнения свойств, присутствующих в объекте, но не предназначенных для (не проверенного) пользовательского ввода, из веб-запроса. Примером может служить запрос POST, создающий ресурс. Если обработчик запроса берет полный объект ресурса и заполняет только отсутствующие свойства, злоумышленник может заполнить поля, которые он не сможет редактировать.

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

GET http://yourhost/findDocSearch/byName?name=Abuse&zipCode=11111

дополнительный zipCode будет просто проигнорирован. Поэтому предполагаемого риска здесь нет.

Чтобы исправить предупреждение, вы можете пометить его как ложное срабатывание (если это возможно в вашей настройке). Если это невозможно, вы также можете просто сопоставить параметры запроса напрямую с аргументами метода. Поскольку у вас есть только ограниченные параметры, которые не должны причинить слишком много вреда. Если это также не вариант, вам, вероятно, нужно выяснить точный алгоритм, который использует ваш анализ кода, чтобы выяснить, какие проверки он распознает. К сожалению, большинство сканеров могут обнаружить только ограниченный набор способов проверки ввода.

Answer 5

Простой вопрос - как ваш маппер может создать бин? Вот ответ / пример. Вы можете передать эти данные по query parameterили в header, Однако это было бы странно. Лучше иметь эти методы с @QueryParam предоставляя местоположение или имя. Таким образом, будет проще защитить ваше приложение.

Как примечание, запрос имеет ограниченную длину, поэтому, если ваша форма поиска большая и странная, @POST может быть хорошей идеей, и таким образом вы можете передать все данные. Для этого простой пример, который был бы излишним.