-
-
Notifications
You must be signed in to change notification settings - Fork 9
Images not sent to ILS - unexpected failure on Burp Inferred-Mime-Type API #26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
After enabling debugging, we see that mimeInferred is empty. Added ❓ to logs to better indicate the missing value. The oddity is that the inferred type is correctly shown in the proxy logs and target logs.
The code was modified to use the HTTP Header mimetype (aka Stated) and we can see that ILS does process a file and detect an information leakage.
Other instances:
|
Fixed by check mimeStated, mimeInferred, or file extension for one of our valid mime types |
Uh oh!
There was an error while loading. Please reload this page.
ILS has used Burp's inferred mime type API call since nearly the beginning - it worked perfectly and ILS didn't have to re-process the mime type HTTP header or scan the response body for the file type (thus repeating processing Burp already did).
But, now, when use the latest 2025.4.x builds of Burp (and perhaps earlier...), the v1.1 ILS software in the B-App store and build-from-source software both fail to detect GPS info in nearly all image files - ILS is not getting triggered on images, the "inferred MIME type" seems to fail and images don't get sent to ILS.
The text was updated successfully, but these errors were encountered: