Your site doesn't use https. It's a bit late to put the clear message after people send sensitive data over an insecure connection.

Check again, there was a short period of a few minutes without https when I switched off Cloudflare, but now all http requests are redirected to https.

Glad that wasn't the case while your site was still phishing!

Yep. Even though it posts to https://127.0.0.1 since the page itself isn't https it could have scripts injected into it over the wire.

Despite having 127.0.0.1 in the action field, the form does not actually submit, you can verify with the dev tools.

If scripts were injected into it, how do you know the form would not submit?

The problem was corrected. Its not the site owners fault Equifax cant link to the correct site.

No form data is sent. Only an active MiTM would make this a risk.

But the server page with the form could be MiTM, is the point.

Devil's advocate: how does anyone know you're not actually phishing with this site?

You can watch the network using the network tab in devtools. No data is sent on the form's page.

My point is, a layman may not know that, a judge may not care.

>a judge may not care

Why? This seems like clear and compelling evidence that the site was not designed to actually phish.

Was the site not designed to actually phish?

- The site contains Equifax's heading, uses their branding, and is highly similar to the actual website

- The site is hosted on a domain that is very similar to the actual website and uses Equifax's name

- The site instructs users to enter PII on it under the guise of being Equifax.

It could be argued that the creator of the site created this to determine whether people were being phished by it before activating the actual collection of data.

Additionally, in Chrome, when I fill out the form and get the alert box, when I dismiss the alert box, two requests are made to the domain:

https://securityequifax2017.com/eligibility/images/favicon-3... https://securityequifax2017.com/eligibility/images/favicon-1...

If an onSubmit handler is attached to the form submit that sets a cookie with this information before showing the alert, then the phished details are transmitted to securityequifax2017.com.

Lawyers will C&D this extremely hard, a very reasonable case can be made that this is impersonation, and a phishing site with malicious intent.

NB: I DO NOT BELIEVE THAT THIS IS THE CREATOR'S INTENT. So do not jump at me thinking that I do believe that. I'm just saying that it could be very reasonably and successfully argued, and that nuance and intent could do very little to spurn allegations of impersonation or actual phishing.

Except that the data isn't actually submitted. Look at the dev console network tab. Those are favicon images. smh

Your cookies are submitted with requests for anything from a site, favicon images included. Setting a cookie in JS that contains events performed on a webpage is a trivial exercise and you shouldn't assume that that doesn't happen in a case such as this.

What if it only sends HTML that sends data back under certain conditions? E.g. 1 in 1000 requests, at random. A security researcher is unlikely to hit the "bad" version but he can still phish 0.1% of victims.

Then, under U.S. law, this would need to be positively proven in court.

"What if"s don't produce convictions.

But you said "anyone" in a programmer-friendly thread.

Fair enough, I will be trampled by pedantry then!

A judge may not care about anything then. They may not care about a big disclaimer either.

If I were you I'd pop up an alert on clicking or tabbing into any of the form fields. It would get the message across without someone having to enter their private information into a page served over an insecure connection.

It was only briefly served via http while I switched off cloudflare, everything is redirected to https now.

Thats great to hear. Good job making them look like the fools they ard by the way.

s/loose/lose on that alert box

Fixed, thanks.