Description
So... This lab has a java deserialization in the cookie, which is base64 + url encoded
https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-exploiting-java-deserialization-with-apache-commons
When I send the request to Java deserialization scanner and I set the cookie as insertion point, and I do manual testing, it cannot find any vulnerability. Burp logger shows why: all requests return 403 forbidden and Newlines in headers are not allowed in the body.
The funny thing is that if I send the same request to Repeater, it receives a 500 Internal server error (correctly).
When I send the JavaDeserializationScanner request from Logger to Comparer, and I compare it with the one from Repeater, I can see the difference: in the one sent by Repeater there is an extra byte %0d before a %0a, exactly between the end of the serialized cookie and the beginning of the next Header (Cache-control). It looks like that just by sending the request that received 403 Forbidden, from Logger to Repeater, a %0d is added automatically and that fixes the "Newlines in headers are not allowed" error.
Very weird... not sure why JavaDeserializationScanner fails: I think it's related to setting the insertion point. Even more weird the fact that with an automatic scan (scan insertion points - extensions only), the extension correctly finds the deserialization vulnerability
Using the latest ysoserial-master-8eb5cbfbf6-1.jar and java 11.