0

One of the findings arises from penetration testing is "Query Parameter in SSL Request" for the following 4 URLs. The value passed for the query parameter ln is primefaces (ln=primefaces). It is primefaces jsf library so we don't specifically passed other value to the query parameter ln. How to confirm this?

https://example.com/BelsizeWeb/faces/javax.faces.resource/primefaces.js

https://example.com/BelsizeWeb/faces/javax.faces.resource/jquery/jquery-plugins.js

https://example.com/BelsizeWeb/faces/javax.faces.resource/jquery/jquery.js

https://example.com/BelsizeWeb/faces/javax.faces.resource/fileupload/fileupload.js

Entity: ln (Parameter)

Causes: Query parameters were passed over SSL, and may contain sensitive information

bittersour
  • 937
  • 2
  • 11
  • 32
  • Check your access logs? – jedifans Aug 31 '16 at 07:27
  • Note: It's not secure to send sensitive information in url parameters, you should use POST to send them : https://stackoverflow.com/questions/830074/can-a-username-and-password-be-sent-safely-over-https-via-url-parameters#comment64701408_830074 – Tom Aug 31 '16 at 11:11
  • @jedifans I checked the access log and it is showing ln=primefaces only, nothing else. How the ln=primefaces got appended the to above URLs? – bittersour Sep 01 '16 at 01:43
  • It's not an automatic browser thing, so check your codebase – jedifans Sep 01 '16 at 06:45
  • @jedifans where should I check? I am thinking could it be some codes at the xhtml namespace (e.g. xmlns:p="http://primefaces.org/ui") or h:head tag (e.g. ) ? – bittersour Sep 02 '16 at 03:57
  • @bittersour Recursively search your entire codebase if you don't know where it is. On *nix: `grep -R ln=primefaces /path/to/codebase` – jedifans Sep 02 '16 at 06:36
  • The ln parameter most probably is coming from PrimeFaces Extension library. Check the code parts where that is initialized. Even though this may be a false positive if the input is somehow being sanitized inside the library. Anyway you can try making request manually to the reported URL's by tampering the ln parameter and observing the output. – Trim Kadriu Sep 14 '16 at 09:25

1 Answers1

2

Your penetration testing tool is making the following bogus assumptions about any query parameter:

  1. The value contains sensitive data (e.g. password)
  2. Is accessible (to malicious JavaScript) via the browser history
  3. Would be logged on the backend server

The first is false most of the time, in which case the other issues don't even matter.

Even when 1 it is true, only the requests made for a webpage (URLs that appears in the address bar) end up in the history. XHR requests and other requests for images, css, js, etc. do not.

The last concern is pretty flawed. If URLs are being logged, passing the sensitive data as path segments is no better, yet I'm guessing your tool complains about GET /endpoint?code=xyz123 but not GET /endpoint/code/xyz123. A POSTed form is another option, but when 2. does not apply, the only benefit to a POST would be if someone who as access to the logs would not otherwise have access to the incoming data (and you're sure that the POSTed form is not logged).

To summarize, you should use a POSTed url encoded form whenever 1 & 2, or 1 & 3 apply to your situation. Common examples:

  • forms that submit a user's password using POST
  • using a self-submitting form (and not query params in a redirect) to pass a "token" from one domain to another (e.g. OIDC).
Randy Hudson
  • 1,600
  • 1
  • 12
  • 11