by vitalipom on 1/27/2025, 8:32:24 PM with 5 comments
I found a security bug that allows a phishing website to pretend to be the real website and sniff user’s credentials. It exists almost EVERYWHERE. I did my own research, experimenting on myself in some common websites whilst following up a question which I asked here on what prevents this from happening. And apparently most of the websites do not prevent such an obvious phishing use case. And not only, but I’m also up to digging a little bit more and writing my own (paid - sorry guys) tutorial on how to raise a secure and safe website on Amazon AWS with a secure login and credentials for a non tycoon average user.
It was a great journey. My patent herby goes to trash since there are non Saas solution which are utilized to defend against phishing. And I am about to start a new journey where I begin to build a secure web portal which tells its users how to build a secure web portal with their own users!
The attack I mentioned allows to present a login page using a proxy of any webpage on a non webpage’s domain. Which in turn allows either a session hijacking or credentials sniffing.
My patent suggested transferring a secret token to the user’s email box in order to create a third channel of communication whereas the attacker so or so does not have an access to the user’s email box. Nor to the 3rd Saas security service that secures the communication between the client and the attacked host with that token.
What I’ve seen that is being used instead is splitting the login into username and ON ANOTHER page password, which is defended by CORS - since once username is entered and the Next button is clicked, there is a CORS issue which arises because the fake login page is being served on the fake domain which does not have the permission to go on with the cross origin request to the next page after entering the username where password is required.
It was a great journey. My patent herby goes to trash since there are non Saas solution which are utilized to defend against phishing. And I am about to start a new journey where I begin to build a secure web portal which tells its users how to build a secure web portal with their own users!
The attack I mentioned allows to present a login page using a proxy of any webpage on a non webpage’s domain. Which in turn allows either a session hijacking or credentials sniffing.
My patent suggested transferring a secret token to the user’s email box in order to create a third channel of communication whereas the attacker so or so does not have an access to the user’s email box. Nor to the 3rd Saas security service that secures the communication between the client and the attacked host with that token.
What I’ve seen that is being used instead is splitting the login into username and ON ANOTHER page password, which is defended by CORS - since once username is entered and the Next button is clicked, there is a CORS issue which arises because the fake login page is being served on the fake domain which does not have the permission to go on with the cross origin request to the next page after entering the username where password is required.