Standalone man-in-the-middle attack framework used for phishing login credentials along with session cookies, allowing for the bypass of 2-factor authentication
First and foremost, thank you so much for this amazing tool !
Recently, I encountered an issue having to do with a CORS preflight request.
For a bit of context : the website I was proxying is on a first subdomain and queries a JSON API on another subdomain to authenticate the user, hence the preflight request (both are in the proxied subdomains section of the phishlet).
The problem is that when the OPTIONS request is sent to, it is flagged as unauthorized by Evilginx and redirected to Youtube because it does not contain the tracking cookie set by Evilginx (as preflight requests don't include credentials : https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflight_requests_and_credentials). Needless to say, this breaks the authentication process.
The workaround I came up with is to submit the authentication request as a regular POST (hopefully the API accepts it but it won't always be the case). It would be nice if Evilginx responded to unauthenticated preflight requests by automatically whitelisting the requesting domain instead of treating it as unauthorized.
Also note that if the preflight request includes the tracking cookie (added with Burp for instance), Evilginx forwards it as normal and everything works fine but as I understand browsers won't include the cookie. Evilginx could also recognize this case and forward the OPTIONS request anyway.
Don't know if it has something to do with anything but I am using v2.4.0.
Hello,
First and foremost, thank you so much for this amazing tool !
Recently, I encountered an issue having to do with a CORS preflight request. For a bit of context : the website I was proxying is on a first subdomain and queries a JSON API on another subdomain to authenticate the user, hence the preflight request (both are in the proxied subdomains section of the phishlet).
The problem is that when the OPTIONS request is sent to, it is flagged as unauthorized by Evilginx and redirected to Youtube because it does not contain the tracking cookie set by Evilginx (as preflight requests don't include credentials : https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflight_requests_and_credentials). Needless to say, this breaks the authentication process.
The workaround I came up with is to submit the authentication request as a regular POST (hopefully the API accepts it but it won't always be the case). It would be nice if Evilginx responded to unauthenticated preflight requests by automatically whitelisting the requesting domain instead of treating it as unauthorized.
Also note that if the preflight request includes the tracking cookie (added with Burp for instance), Evilginx forwards it as normal and everything works fine but as I understand browsers won't include the cookie. Evilginx could also recognize this case and forward the OPTIONS request anyway.
Don't know if it has something to do with anything but I am using v2.4.0.
Have a good day,