Is it possible to 'pretend' a site is a third party to test functionality if 3rd party cookies are blocked? - firefox

I do automation testing for a company that is trying to implement a single sign on via an iFrame; a third party site will include our page in an iFrame and we will do an authorization.
We had to rework the way this worked because of Firefox defaulting to 3rd Party Cookies being off. For manual testing, we have hosted the page on a different domain, but this domain requires certain usernames and passwords we cannot expose in code, so this is difficult to automate.
Is there a way I can trick Firefox into thinking that mydomain.com is not actually mydomain.com? This sounds impossible, because if I can trick Firefox into thinking I'm actually on mydomain2.com, then I can effectively just put on a 3rd party cookie, but since I'm doing it on my own instance of Firefox, are there any settings I can change in my profile to confuse it?

Yes, this is incredibly easy and we do this all the time.
Log onto the test machine (the computer that will be running the browser) and edit the hosts file, located in c:\windows\system\drivers\etc
Add an entry for the site you wish to be confused, using a different domain name but the correct IP address. Because it's a different domain, it'll look like a third party site, but because the IP address is the same, the requests will actually be sent to the same web server.
Example:
Assume your web server is running on the local host (which has address 127.0.0.1)
Add host entries for
127.0.0.1 FirstPartyDomain.com
127.0.0.1 ThirdPartyDomain.com
Access your site via http://FirstPartyDomain.com
Site contains an iFrame
<iframe src="ThirdPartyDomain.com/SetNastyCookies">
The request in the iFrame will go to the same server (local host) but in the context of a third party site.

What about using DNSMasq? Most open-sourced routers such as DD-WRT support this option. If you need to test it via https, you could also temporarily store security certificate exceptions as well during your testing.

Related

Running ASP.Net Web Api inside intranet - cert authority invalid

I made simple API for which is running on my "server" inside local network. When I want to call api from another PC internet browser inside my intranet over https://xxx.xxx.xxx.xxx:9100/ShowList i get warning from my browser that my connection is not private NET:ERR_CERT_AUTHORITY_INVALID. I can proceed as unsafe but i would like to avoid that. The question is what I have to do to have save connection inside my intranet? I'm totally new in that so i'm aware of thing I have to do.
You just need to add a ssl certificate to the hosting IIS server (assuming you are using IIS as the server). You can create a Self-Signed Certificate, buy from the vendors or use free services. Take a look at
https://learn.microsoft.com/en-us/iis/manage/configuring-security/how-to-set-up-ssl-on-iis

Windows authentication box pops up with integrated authentication on web page

I am running two Windows server 2016s with IIS 10.0.14393. One server for staging purposes, and one for production.
The application has one "front-end app" and one "back-end REST api" running on the same IIS server. The front end communicates with the backend (suprise!). The difficulty I am facing is that the staging server works as expected, i.e no "Sign in" box appears when entering the front-end web page (React). However, on the production server this box pops-up.
When the page is loaded, there is javascript that fetches some information from the API, and it seems that this async fetch is causing the pop-up to occur (the request is in pending mode until login).
I have studied the configuration of IIS on the two servers but can't seem to find any obvious differences.
Both instances have both windows authentication and anonymous authentication turned on for both front-end and backe-end. I need this as the API has different types of authentication for the endpoints.
Anyone that has solved a similar issue?
Thanks
If someone experiences a similar issue the following link may help: https://support.microsoft.com/en-us/help/258063/internet-explorer-may-prompt-you-for-a-password
In my case I was sending the request to the api with the full domain url. The problem was fixed by just using the machine name (and port in my case) when sending the request. If the whole domain with punctuation is used, the system believes that the request is meant for the Internet and not the intranet, and will not include any credentials.
Another, and probably more robust solution, is to add the site in question to: Internet properties -> security -> Local intranet -> sites -> advanced.

How to identify computer which I have redirected

I have the following problem to solve:
I few months ago I startet a website where you can watch youtube videos which aren't available in your country. Everythings works fine but now I want to offer a new method where I route all the requests directly over my server. Therefore I will later use a custom DNS-Server. Right now I use the hosts file for testing but I have really no idea how i can identify the user. I can promp the user user to login on a website but I will that it works systemwide so if he use a youtube downloader for example it have to work there either and not only in the browser where I could use a session system with cookies. I want a solution where the user can identify himself once in a time like a website or something like this but how can my server detect if this is a user which is logged in or if he is not?
There are several ways that this could be accomplished with varying levels of difficulty.
standard proxy server over https. Your service could simply be a proxy server and then every "client" would update their browser to point to your proxy server. You could also simplify this by using a proxy PAC file (proxy auto config).
An anonomyzing interface. The end user would not be able to use their standard search tools etc, instead they would have to use a web page much like what google translate does.
A browser plugin. There are already firefox plugins which do something similar to this. They change the way that the browser resolves DNS. This may be the best bet for you but would require development work.
An actual install utility that you have your users install on their machines which update the dns servers.

Machine dependent web application login

Is there a way to limit the login to a web application based on client machine name or id. The requirement is a certain userid login should be done only from pre-determined or preset systems.
Hope this covers the queries mentioned.
I am not sure if IP address of the machine can be used as much effective as the machine name or macid may server the purpose.
Client OS can be windows or mac. Its a public facing site but a certain group of users should login from certain machines only.
The site is php, mysql and hosted on apache and linux.
Generally speaking, a web browser will only send basic HTTP headers along for the ride, in addition to a known IP address.
Assuming you even could get this information from the client system via javascript, it would not be trustable, (eg, a client could fake it).
Perhaps you can expand your question a bit?

What is the best way to restrict access to a development website?

I have a site i am working on that i would like to display only to a few others for now. Is there anything wrong with setting up windows user names and using windows auth to prompt the user before getting into the development site?
There are several ways, with varying degrees of security:
Don't put it on the internet - put it on a private network, and use a VPN to access it
Restrict access with HTTP authentication (as you suggest). The downside to this is it can interfere with the actual site, if you are using HTTP auth, or some other type of authentication as part of the application.
Restrict access based on remote IP. Just allow the IPs of users you want to be able to access it.
Use a custom hostname. Have it on a public IP, but don't publish the hostname. This means make an entry in your HOSTS file (or configure your own DNS server, if possible) so that "blah.mysite.com" goes to the site, but that is not available on the internet. Obviously you'd only make the site accessible when using that hostname (and not the IP).
That depends on what you mean by "best": for example, do you mean "easiest" or "most secure"?
The best way might be to have it on a private network, which you attach to via VPN.
I do this frequently. I use Hamachi to allow them to access my dev box so they can see whats going on. they have access to it when they want , and/or when I allow. When they are done I evict them from my Hamachi network and change the password.
Hamachi is a software VPN. Heres a link to Hamachi - AKA LogMeIn
Hamachi
They have a free version which works quite well.
Of course, there's nothing wrong with Windows auth. There are couple of (not too big) drawbacks, though:
your website auth scheme is different from the final product.
you are giving them more access to the box they really need.
you automatically reimaging the machine and redeploying the website is more complex, as you have to automate the windows account creation.
I would suggest two alternatives:
to do whatever auth you plan on doing in the final website and make sure all pager require auth
do a token cookie based auth - send them a link that sets a particular token in a cookie and in your website code add quick check for that token before you even go to the regular user auth
If you aren't married to IIS, and you need developers to be able to change the content, I would consider Apache + SSL + WebDav (aka Web Folders). This will allow you to offer a secure sandbox where developers can change and view the content without having user accounts on the server.
This setup requires some knowledge of Apache so it only makes sense if you are already using Apache or if you frequently need to provide outsiders access to your web server.
First useful link I found on the topic: http://pascal.thivent.name/2007/08/howto-setup-apache-224-webdav-under.html
Why don't you just set up an NTFS user and assign it to the website (and remove anonymous access)

Resources