7 ms·

Missing anti pattern: consider URLs insecure, especially if for a web browser. Don't include customer details (name, email, account number, etc) or search queri

Missing anti pattern: consider URLs insecure, especially if for a web browser. Don't include customer details (name, email, account number, etc) or search queries (free text) unless you have determined the security settings on your logging, audit, proxies, .., all conform to data protection requirements that suggest they should be encrypted and only visible to necessary staff. If you expect pages to be bookmarked or shared, then consider the security impact of where they are stored on local machines too, including in caches if your company is silly enough not to enforce disk encryption for all users.

rhizome 9y ago
data protection requirements... Link?
- blowski 9y ago
  PCI DSS is a related example. You can't store credit card data in your logs.
Sohcahtoa82 9y ago
> consider URLs insecure, especially if for a web browser. A web site I used recently puts your session ID in the URL. If you log in, then alter the URL to remove the session ID, you appear logged out. It gets even worse. Clicking the "Log out" button on the page simply removes the session ID from the URL. If you go back and reload the web page with the session ID in it again, you still appear logged in. The page also doesn't use HSTS so is easily vulnerable to SSLStrip.
- LgWoodenBadger 9y ago
  This is common in servlet-container-land (Java) for handling browsers that don't support cookies. The URLs are rewritten to include the session-identifier (usually a cookie) as a request parameter instead. There's no other mechanism to associate an HTTP request with back-end state (logged-in/out, etc.) except for session identifiers transmitted by the client browser (through cookies, headers, request parameters).
- naasking 9y ago
  > A web site I used recently puts your session ID in the URL. If you log in, then alter the URL to remove the session ID, you appear logged out. Nothing inherently wrong with that, but it depends on the situation. > Clicking the "Log out" button on the page simply removes the session ID from the URL. If you go back and reload the web page with the session ID in it again, you still appear logged in. That's bad.

rhizome 9y ago

data protection requirements... Link?

blowski 9y ago
PCI DSS is a related example. You can't store credit card data in your logs.

Sohcahtoa82 9y ago

> consider URLs insecure, especially if for a web browser. A web site I used recently puts your session ID in the URL. If you log in, then alter the URL to remove the session ID, you appear logged out. It gets even worse. Clicking the "Log out" button on the page simply removes the session ID from the URL. If you go back and reload the web page with the session ID in it again, you still appear logged in. The page also doesn't use HSTS so is easily vulnerable to SSLStrip.

LgWoodenBadger 9y ago
This is common in servlet-container-land (Java) for handling browsers that don't support cookies. The URLs are rewritten to include the session-identifier (usually a cookie) as a request parameter instead. There's no other mechanism to associate an HTTP request with back-end state (logged-in/out, etc.) except for session identifiers transmitted by the client browser (through cookies, headers, request parameters).
naasking 9y ago
> A web site I used recently puts your session ID in the URL. If you log in, then alter the URL to remove the session ID, you appear logged out. Nothing inherently wrong with that, but it depends on the situation. > Clicking the "Log out" button on the page simply removes the session ID from the URL. If you go back and reload the web page with the session ID in it again, you still appear logged in. That's bad.