How to Protect API from Domain Manipulation in Hosts File?

Question

I want to know if 'domain manipulation,' for lack of a better term, is a real thing when it comes to getting around CORS and/or referrer checks in HTTP.

Right now our team is working on a public informational site that pulls content dynamically from our SQL Server database. There is no login; all users are--technically speaking--"anonymous."

The site itself is static HTML, CSS and jQuery, but operates within a .NET project/application (IIS 10.0). The APIs called to get the content data are in a separate .NET Web API application & app pool.

We're utilizing machine-to-machine JWT authentication to access the APIs from the site; for each API used, every time the app pool is recycled/started, a new token request is sent to our Auth0 tenant, an access_token is returned and stored in an Application variable. This works well for us.

'from Application_Start in global.asax.vb ("apiHlpr" is a custom class):

        '. . .
        For Each apiName As String In apiNameList    '<-- pulls specific keys from <appSettings>
            Dim tkn As String = apiHlpr.GetSignedJWT(apiName, clientID, clientSec) 
            tkn = "Bearer " & tkn
            Application.Add("keyPrefix_" & apiName, tkn)
        Next

To tighten up access restriction a little further, we use a webservice to encrypt the token before passing it through the request header to the API...

'snippet from our asmx webservice ("ourLibrary" is a custom class library):

    <WebMethod()>
    Public Function tkn(ByVal name As String) As Object
        Dim authBearer As String = HttpContext.Current.Application("keyPrefix_" & name).ToString.Trim()
        Dim strHlpr As New ourLibrary.StringHelper      
        authBearer = strHlpr.EncryptString(authBearer) 
        Dim token As New With {
            .bearer = authBearer
        }
        Return token
    End Function

...which first checks if HttpContext.Current.Request.UrlReferrer starts with our site's domain; if it does, the token is decrypted server-side and then validated. This also works well.

'snippet from our API's controller ("strHlpr" and "apiHlpr" are custom classes):

        Dim token As String = auth.BearerToken()

        If auth.ValidReferrer(HttpContext.Current.Request.UrlReferrer) Then
            token = strHlpr.DecryptString(token)
        End If

        Dim status As String = apiHlpr.ValidateToken(token)
        
        '''proceed with validation and retrieve data if validated...

'from auth.vb:

    Public Function ValidReferrer(ByVal ref As Uri) As Boolean
        If Not IsNothing(ref) Then
            Dim str As String = ref.ToString
            Dim domain As String = AppSettings("DOMAINGOESHERE").Trim()
            If str.ToLower.StartsWith(domain) Then
                Return True
            Else
                Return False
            End If
        Else
            Return False
        End If
    End Function

The results:

• When the API is called from the site, the content is retrieved successfully, AND...
• Going into the Network tab of the browser to try to snatch the access_token, the user will see an encrypted string instead of the unencrypted token
• When attempting to go directly to the API request url, whether by hyperlink in a different domain, direct copy-paste input into the browser, or by Postman (trying to paste the encrypted string into the "authorization" header), a 401 (Unauthorized) error is returned--which is good, of course.

HOWEVER...if we were to move forward with this technique, and/or implement CORS, we have one nagging issue, which I've not seen fully answered in all our searches so far:

What's to stop someone from creating their own page with a link to the API's url, then customizing their local Hosts file so that their page has our site's domain, thus accessing our data through their "dummy page"?

Answer 1

If you do “domain manipulation” in the Hosts file on some other person’s computer — or on a shared computer — then you may be able to use their credentials and privileges for an attack.

But doing domain manipulation in the Hosts file on just your own computer won’t give you access to privileges or credentials you don’t already have.

If you have no credentials or privileges at trusted.example.com but you alter your own Hosts file to make your computer think some other site is trusted.example.com, that’s still not going to give you access to any credentials or privileges at the real trusted.example.com.

CORS isn’t fragile against one person doing domain manipulation on one computer. It’s not possible to do much of anything nefarious just by domain manipulation on your own computer.

Consider also that to do what’s described in the question, you wouldn’t even need admin perms to change a Hosts file; instead you could clone the source code for Chrome or Safari or Firefox and change it and build a version of the browser to make it think that it’s running trusted code from trusted.example.com when in fact it’s actually running code from evil.example.com.

But if you don’t actually have credentials or privileges at trusted.example.com, that hacked browser isn’t going to give you access to those credentials and privileges.

To be able to use such a hacked browser for an attack, you’d need to get that browser onto a different computer being used by someone who does have trusted.example.com credentials and privileges — or else, I guess, somehow trick them into sitting down at your computer and navigating to trusted.example.com and logging in, etc.

So in general, if one person wilfully confuses just their own computer by “domain manipulation” as the question describes, there’s no real-world CORS attack that’ll enable.