3

One of my company's clients recently produced an application security assessment report, noting a list of violations based on OWASP's top 10 list of web application security risks. One of the violations, based on OWASP's #3 risk, is that sensitive data is present in browser history. This can be both in the query strings (as in "myurl.com/somepage?userid=user123") or in the url segments themselves (as in "myurl.com/users/user123/edit").

The idea is that an adversary with access to the victim's system will be able to gain access to sensitive data just by viewing the browser history and seeing the data in the urls.

Question:

What are ways to solve this? For query string parameters, I know you can simply change the form method from GET to POST - are there any other ways to handle the query string parameters? What about handling data in the url segments?

Improve this question
1
  • the whole url is typically stored locally in the browser's history, which is the issue.
    – dandavis
    Apr 16, 2020 at 18:25

1 Answer 1

Reset to default
2

It's difficult without a global overview to answer your question. If the only problem on your website was sensitive parameters are present in the URL: As you said, just pass the request as POST and not GET.

However : You need to check theses points :

  • Be sure communications are encrypted using TLS 1.2 or TLS 1.3
  • Your server must purpose only robust and non deprecated encryption algorithms. You can use this website to check it or this project if you need privacy.
  • Check for broken access control. You said that query string use the pattern userid=user123 : check that an attacker can't access to an illegitimate account changing the parameter of the request
  • Check for SQL injection. The pattern page=parameter (userid=user123) is often implemented on old web site and so more susceptible to be vulnerable. Be careful you can also inject in POST request and other ways

You need also check all TOP 10 OWASP recommendation but according to the information you gave, it's the first point I would check.

Conclusion

  1. What are ways to solve this? Change GET method to POST

  2. What about handling data in the url segments? I am not against the idea of username appears in the URL. It's not a vulnerability if access is controlled. Indeed if an attacker steal the computer it could have access to the history and so the username. However It should not have access to the password if security standards of storage password are respected. Moreover, if an attacker steal a computer which have not an encrypted hard drive, you will have more than the username problem...

    If you absolutely needs to solve this problem, you should encrypt the user's computer hard drive of the application. In consequences, if the computer is stolen (and turned off), data will not be available.

Improve this answer
2
  • What if the only issue on my website is PII in the url segments, as in "myurl.com/user/user123/edit". Would it be considered an issue that PII shows up in the browser history? (I would think it could be -- let's say someone physically steals your computer - then they can see user id, etc. in browser history even if they're not logged in). Is there a common way to handle this?
    – jbyrd
    Apr 16, 2020 at 18:46
  • I just edited my answer. Say me if it not respond to the question.
    – Anonymous
    Apr 17, 2020 at 18:39

You must log in to answer this question.

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