Burp suite прекрасно справляется с поиском XXE, но как и любое DAST решение, он должен знать формат запросов для вашего приложения. Конкретно, на какие URLs отправлять запросы и с какими query и post body параметрами.
В вашем случае, просто запустите сканирование и посмотрите во вкладку "Logger" в Burp Suite, там отображаются все запросы к серверу. Убедитесь что сканер правильно подхватил формат запроса к контроллеру "/bill" в котором находится уязвимость.
"Logger" предоставит вам гораздо больше информации что сделал или не сделал сканер чем JaCoCo.
> если подписывать на сервере, то клиент не сможет объект менять. На хрена бы клиенту неизменяемый объект?)
В PayPal и не подразумевалось что клиент будет менять этот объект. Там на клиенте только html/js и с помощью них менять сериализованный объект Java было бы странно. Объект использовался только для сохранения состояния клиента, что по моему скромному мнению может быть и должно быть сохранено в сессии.
> если подписывать на клиенте, то клиент сможет объект менять, как хочет. На хрена бы нужна такая подпись?)
В этом случае подпись действительно не нужна, если очень хочется использовать сериализацию в общении java -> java, то можно ограничить список классов, которые могут быть сериализованы написанием своего ObjectInputStream. Некоторые просто советуют удалить класс из Commons Collections который приводит к RCE, но мне не кажется что это лучшее решение.
В коде приложения десериализация выглядит примерно так:
ObjectInputStream oin = new ObjectInputStream(Base64.decodeBase64(request.getParameter("xxx")));
MyСlass obj = oin.readObject();
При этом имя класса у которого будет вызван readObject хранится в байтах самого сериализованного объекта, который мы можем подделать, а преобразование к нужному экземпляру класса(MyClass) происходит уже после вызова readObject.
В классе sun.reflect.annotation.AnnotationInvocationHandler, который я использовал, как раз в методе readObject содержится нужная мне последовательность действий, приводящая к выполнению произвольного кода.
>Еще более непонятно, в чем отличие варианта, когда сервер проверяет подпись. Если файл динамически генерируется и подписывается >клиентом, то что помешает злоумышленнику точно так же подписать свой класс с вредоносной нагрузкой и отправить его на сервер?
Объект проходит сериализацию/десериализацию только на сервере, поэтому подпись тоже должна выполняться только на сервере. Либо можно хранить сериализованные объекты в сессии, а не принимать их от клиента через Post/Get параметры.
Burp suite прекрасно справляется с поиском XXE, но как и любое DAST решение, он должен знать формат запросов для вашего приложения. Конкретно, на какие URLs отправлять запросы и с какими query и post body параметрами.
В вашем случае, просто запустите сканирование и посмотрите во вкладку "Logger" в Burp Suite, там отображаются все запросы к серверу. Убедитесь что сканер правильно подхватил формат запроса к контроллеру "/bill" в котором находится уязвимость.
"Logger" предоставит вам гораздо больше информации что сделал или не сделал сканер чем JaCoCo.
В PayPal и не подразумевалось что клиент будет менять этот объект. Там на клиенте только html/js и с помощью них менять сериализованный объект Java было бы странно. Объект использовался только для сохранения состояния клиента, что по моему скромному мнению может быть и должно быть сохранено в сессии.
> если подписывать на клиенте, то клиент сможет объект менять, как хочет. На хрена бы нужна такая подпись?)
В этом случае подпись действительно не нужна, если очень хочется использовать сериализацию в общении java -> java, то можно ограничить список классов, которые могут быть сериализованы написанием своего ObjectInputStream. Некоторые просто советуют удалить класс из Commons Collections который приводит к RCE, но мне не кажется что это лучшее решение.
В коде приложения десериализация выглядит примерно так:
При этом имя класса у которого будет вызван readObject хранится в байтах самого сериализованного объекта, который мы можем подделать, а преобразование к нужному экземпляру класса(MyClass) происходит уже после вызова readObject.
В классе sun.reflect.annotation.AnnotationInvocationHandler, который я использовал, как раз в методе readObject содержится нужная мне последовательность действий, приводящая к выполнению произвольного кода.
>Еще более непонятно, в чем отличие варианта, когда сервер проверяет подпись. Если файл динамически генерируется и подписывается >клиентом, то что помешает злоумышленнику точно так же подписать свой класс с вредоносной нагрузкой и отправить его на сервер?
Объект проходит сериализацию/десериализацию только на сервере, поэтому подпись тоже должна выполняться только на сервере. Либо можно хранить сериализованные объекты в сессии, а не принимать их от клиента через Post/Get параметры.