You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
J2EEScan scans for Struts class loader manipulation ( https://github.com/ilmila/J2EEScan/blob/master/src/main/java/burp/j2ee/issues/impl/ApacheStrutsS2020.java ) with the type of payload engineered AFTER the first fix which is Class.classLoader Ex:
Class.classLoader.URLs[0]=testClassloaderManipulation1509723031
During testing I've seen that most of the times this payload will not trigger anything/any reaction , but the original one , class.classLoader would . I did class.classLoader.classAssertionStatus=test , this , in turn , would either generate a beanutils error regarding the fact that classAssertionStatus has no setter or give a 404 in the response. J2EEScan didn't detect anything wrong with the application even though it was vulnerable to this issue .
My suggestion is the following : Adding class.classLoader and class['classLoader'] to the list of payloads for S2-20 scanning . I really think that this will improve the detection of this issue !
There is also a pretty well explained list of payload for struts vulns here : https://github.com/lanjelot/kb/blob/master/struts
The text was updated successfully, but these errors were encountered:
On 7 November 2017 at 11:07, Alexandru Dracea ***@***.***> wrote:
J2EEScan scans for Struts class loader manipulation (
https://github.com/ilmila/J2EEScan/blob/master/src/main/
java/burp/j2ee/issues/impl/ApacheStrutsS2020.java <http://url> ) with the
type of payload engineered AFTER the first fix which is Class.classLoader
Ex:
Class.classLoader.URLs[0]=testClassloaderManipulation1509723031
During testing I've seen that most of the times this payload will not
trigger anything/any reaction , but the original one , class.classLoader
would . I did class.classLoader.classAssertionStatus=test , this , in
turn , would either generate a beanutils error regarding the fact that
classAssertionStatus has no setter or give a 404 in the response. J2EEScan
didn't detect anything wrong with the application even though it was
vulnerable to this issue .
My suggestion is the following : Adding class.classLoader and
class['classLoader'] to the list of payloads for S2-20 scanning . I really
think that this will improve the detection of this issue !
There is also a pretty well explained list of payload for struts vulns
here :
https://github.com/lanjelot/kb/blob/master/struts <http://url>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#17>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACttAGUJ3V3Us6uFihWUT1PkgBw7wowWks5s0CvPgaJpZM4QUikI>
.
J2EEScan scans for Struts class loader manipulation ( https://github.com/ilmila/J2EEScan/blob/master/src/main/java/burp/j2ee/issues/impl/ApacheStrutsS2020.java ) with the type of payload engineered AFTER the first fix which is Class.classLoader Ex:
Class.classLoader.URLs[0]=testClassloaderManipulation1509723031
During testing I've seen that most of the times this payload will not trigger anything/any reaction , but the original one , class.classLoader would . I did class.classLoader.classAssertionStatus=test , this , in turn , would either generate a beanutils error regarding the fact that classAssertionStatus has no setter or give a 404 in the response. J2EEScan didn't detect anything wrong with the application even though it was vulnerable to this issue .
My suggestion is the following : Adding class.classLoader and class['classLoader'] to the list of payloads for S2-20 scanning . I really think that this will improve the detection of this issue !
There is also a pretty well explained list of payload for struts vulns here :
https://github.com/lanjelot/kb/blob/master/struts
The text was updated successfully, but these errors were encountered: