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
Thank you for this amazing tool. We were able to scan 4 of our /24 networks pretty easily using this tool. I'm going to be including a PR soon for easily scanning a range of IPs instead of having to include a list of IPs individually.
One issue we encountered (and wasted about 4 hours on...) was a CGI script that respected the X-Wap-Profile header. You can find some information about the header below:
Basically, if you provide a URL or XML file to X-Wap-Profile, the server will fetch that file and parse it based on the above specs.
It is weird that our program respected the jndi:ldap:// as a valid URL and ran an HTTP GET request against everything after the :// (a bug in the program we patched quickly). I'm not sure if others will have this same weird edge case that we did, but wanted to at least open a ticket here in case others are searching for why this header is "vulnerable" to JNDI even when java is nowhere to be found in an environment.
The text was updated successfully, but these errors were encountered:
Greetings!
Thank you for this amazing tool. We were able to scan 4 of our /24 networks pretty easily using this tool. I'm going to be including a PR soon for easily scanning a range of IPs instead of having to include a list of IPs individually.
One issue we encountered (and wasted about 4 hours on...) was a CGI script that respected the X-Wap-Profile header. You can find some information about the header below:
https://www.developershome.com/wap/detection/detection.asp?page=profileHeader
https://en.wikipedia.org/wiki/UAProf
https://udger.com/resources/http-request-headers-detail?header=X-Wap-Profile
Basically, if you provide a URL or XML file to X-Wap-Profile, the server will fetch that file and parse it based on the above specs.
It is weird that our program respected the
jndi:ldap://
as a valid URL and ran an HTTP GET request against everything after the://
(a bug in the program we patched quickly). I'm not sure if others will have this same weird edge case that we did, but wanted to at least open a ticket here in case others are searching for why this header is "vulnerable" to JNDI even when java is nowhere to be found in an environment.The text was updated successfully, but these errors were encountered: