In a recent execution of a spider, Burp reported cleartext submission of a password CWE-319, but the evidence in the report is merely the preceding GET request of a non-existant page, redirected via HTTPS to a login page containing the form, which contains a password type field.

The form itself has no "action" attribute and its submission is handled by a javascript which submits form content via HTTPS. Burp is erroneously assigning the url of the redirect (as HTTP no-less) containing the form to the form action (per the report, anyway.) I have no record of any form submission in my logs. Is this a false positive, or am I misinformed?

If it is a false-positive, why does Burp identify it as such. On the other hand, if its accurate, what am I missing?

1 Answer 1


False positives are quite possible, and it sounds like that is probably the case here. However, I would like to point out one potential gotcha to take into consideration. Consider this form, pretending that javascript takes over the form submission and sends data securely:

<form onsubmit="secure_submit()">
    <input type="text" name="username">
    <input type="submit">

(just ignore the fact that inline event handlers aren't actually a good choice - that's just for the sake of the example). The page is served over HTTP but of course the secure_submit function sends your data over https, so you're good to go, right?

Well, not quite. What if the user has noscript enabled, or a javascript bug on the page causes the javascript to break? There is no action attribute, but that actually won't stop the form from submitting anyway. Without an action it will simply submit to the page that hosted it, which in this case was served over http. Further, as long as your inputs have names attached to them, the browser will helpfully include all form input in the submission. Moreover, since I haven't specified the method to use, the browser will send a GET request and whatever I put inside the input fields will end up in URL parameters, therefore ending up in the logs of who-knows-how-many servers in between my computer and the application.

Which is just the long way of saying: even with the details you mentioned, a form served over an HTTP connection can still result in credentials being sent in the clear. To completely avoid the risk of that you would have to do one (or more) of the following things:

  1. Serve the page over HTTPS
  2. Specify an action
  3. Remove the name from the input elements (the browser will no longer include them in the form data)

As for whether or not this is a false positive, it is quite possible, but I'm having a hard time coming up with a comprehensive answer based on your description. Hopefully though the above discussion will help you figure that out yourself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .