CWE-523 is login pages that do not use adequate measures to protect the user name and password while they travel from client to server. It is a plain and common web mistake.
How it happens
The usual causes are small.
- The form action points to an
http://address. - The login page itself loads over HTTP and only the post goes to HTTPS, so the page could be altered on the way.
- HTTPS is used on the main site but a legacy login path, a mobile endpoint or an admin panel was left on HTTP.
- A load balancer ends TLS but the application accepts plain requests too and never redirects them.
<!-- Vulnerable: credentials sent without encryption -->
<form action="http://example.com/login" method="post">
<input name="user"><input name="pw" type="password">
</form>
MITRE's mitigation text makes a second point. Even if the whole site does not use SSL, the login page must. And the login page itself should be served over it, because that lets users check which server they are talking to. A phishing site typically cannot present a valid trusted certificate.
What an attacker gains
The listed impact is gaining privileges or assuming an identity. Anyone who can observe the traffic, such as on shared Wi-Fi or a compromised network device, can read the credentials and sign in as the user.
How to find it
Automated static analysis can find some instances by looking at form targets and endpoint configuration. Direct checks are quick:
curl -sI http://example.com/login | head -n 5
If that returns the page instead of a redirect to HTTPS, the login can be reached without encryption. Also:
- Search templates for
action="http:. - Open the browser network tab on the login page and confirm every request is HTTPS.
- Test every host name and port that serves a login, including admin and API hosts.
- Run a dynamic scan of the site. A web app scan flags forms that post over HTTP.
How to fix it
MITRE's step is to enforce SSL on the login page and on any page used to send credentials or other sensitive data. In practice:
- Serve all login pages over HTTPS only.
- Redirect every HTTP request to HTTPS.
- Set HTTP Strict Transport Security so browsers refuse plain HTTP in future.
- Use relative or HTTPS form targets.
- Mark session cookies
Secureso they are never sent over plain HTTP.
server {
listen 80;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
add_header Strict-Transport-Security "max-age=31536000" always;
}
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
If only the form post uses HTTPS, is it enough?
No. MITRE says the login page itself should be served over SSL, so users can verify the server and the page cannot be tampered with in transit.
