Hacker News Reader

Comment by baby | Hacker News Reader

This sounds pretty cool! What I'm wondering, is how they are intercepting the POST request and at what level?

I have not read yet, but my guess is they are taking all HTTP requests from the page and looking for their dummy username/password and replacing that. Not every login form (though we would like it) is in a form tag w/ an explicit action. Some SPA's will do an AJAX post of JSON w/ the credentials embedded (which is bad practice, but happens).

Actually, the more I think about it, I don't think I want this extension to do that...how does it know how long between when the fake fields are entered and when I press submit? Now I am going to read the paper...

Edit: Yup, the extension intercepts all network traffic even before you click submit. If you, e.g., hash on the client side this password manager will break. If you never click submit, this extension will continue to read all HTTP bytes from the page going back to the server it seems, looking for some strings...not sure the perf implications of this.

Out of curiosity, why is an AJAX post of JSON with credentials embedded bad practice?

Not bad practice from a security perspective per se, just annoying to users that don't want JS, or like the non-password fields to support their browser's features like autocomplete, etc. Granted if it's a SPA, some of that usability shop has sailed. And while any AJAX post is secure normally, many JS implemented login solutions open themselves up to CSRF and other problems.

You can have the form submit to a real address when js is disabled, and disable the form's behavior when js is enabled.

FYI Service workers can intercept and modify requests.

Only for the same origin they were installed on. So a generic solution like this one wouldn't really work as a service worker.

Also it is quite common that extensions ask for to be able to read all traffic. What would be stopping other extensions from being jerks?

Reply on news.ycombinator.com