티스토리 수익 글 보기

My colleague Kevin Stubbings mentioned the topic of DNS rebinding attacks in a  previous blog post. No worries if you haven’t read it yet though—in this article, we’ll walk you through the concept of DNS rebinding from scratch, demystify how it works, and explore why it’s a serious browser-based security issue.

We’ll start by revisiting the same-origin policy, a fundamental part of web security, and show how DNS rebinding bypasses it. You’ll see real-world scenarios where attackers can use this technique to access internal applications running on your local machine or network, even if those apps aren’t meant to be publicly available. We’ll dive into a real vulnerability in the Deluge BitTorrent client, explaining exactly how DNS rebinding could have been used to read arbitrary files from a local system. Finally, we’ll go over practical steps you can take to protect yourself or your application from this often-overlooked but potent attack vector.

Same-origin policy

Same-origin policy (SOP) is a cornerstone of browser security introduced in 1995 by Netscape. The idea behind it is simple: Scripts from webpages of one origin should not be able to access data from a webpage of another origin. For example, nobody wants arbitrary webpages to be able to read their currently logged-in webmail. So that websites can be distinguishable from the next, they’re each defined with a combination of protocol (schema), host (DNS name), and a port number. Any mismatch in these three parts makes the origin different. 

For example, for the webpage: https://www.somedomain.com/sub/page.html possible origin comparisons are the following:

The attack: DNS rebinding

People tend to think running something on localhost completely shields it from the external world. While they understand that they can access what is running on the local machine from their local browser, they miss that the browser may also become the gateway through which unsolicited visitors get access to the web applications on the same machine or local network. 

Unfortunately, there is a disconnect between the browser security mechanism and networking protocols. If the resolved IP address of the webpage host changes, the browser doesn’t take it into account and treats the webpage as if its origin didn’t change. This can be abused by attackers. 

For example, if an attacker owns the domain name somesite.com and delegates it to a DNS server that is under attacker control, they may initially respond to a DNS lookup with a public IP address, such as 172.217. 22.14, and then switch subsequent lookups to a local network IP address, such as 192.168.0.1 or 127.0.0.1 (i.e. localhost). Javascript loaded from the original somesite.com will run client-side in the browser, and all further requests from it to somesite.com will be directed to the new, now local, IP address. From then on, documents loaded from different IP addresses—but resolved from the same hosts—will be considered to be of the same origin. This gives the attackers the ability to interact with the victim’s local network via Javascript running in the victim’s browser. This makes any web application that runs locally on the same machine or local network as the victim’s browser accessible to the scripts loaded from somesite.com too. 

One catch is that if the web application requires authentication, its cookies are not made available to the attacker. Since the targeted user originally opened somesite.com—and even though subsequent Javascript requests are directed to the new, attacker rebound, IP address—the browser still operates in the context of the somesite.com origin. That means the victim’s browser will not use stored authentication or session context for the locally targeted service name.

Other scenarios could include attackers abusing local VPN routes that are available to the targeted user, allowing access to corporate intranet web applications, for example.

The response: caching 

Browsers try to resist DNS rebinding like this by caching DNS responses, but the defense is far from perfect. Some browsers have implemented Local Network Access (also known as CORS-RFC1918), a new draft W3C specification. It closed some avenues, but still left some bypasses, such as 0.0.0.0 IP address on Linux and MacOS, so the DNS rebinding behavior is very browser and operating system (OS) dependent. There are so many layers involved (browser DNS cache, OS DNS cache, DNS nameservers) that the attack is often considered unreliable and not taken as a real threat. However, there are also tools that can automate attacks such as Tavis Ormandy’s Simple DNS Rebinding Service or NCCGroup’s Singularity of Origin.

A real-world vulnerability

Now let’s dive into technicalities of a real-world vulnerability found in BitTorrent client Deluge (fixed in v2.2.0) and how DNS rebinding could have been used to exploit it.

The Deluge BitTorrent client supports starting two services on system boot: daemon and WebUI. The WebUI web application service may also be started by enabling the WebUI plugin (installed, but disabled by default) in the preferences dialog of the Deluge client. It is also convenient to run the WebUI application permanently on a server in the local network. We found a path traversal in an unauthenticated endpoint of the web application that allowed for arbitrary file read.

def render(self, request):
	log.debug('Requested path: %s', request.lookup_path)
	lookup_path = request.lookup_path.decode()
	for script_type in ('dev', 'debug', 'normal'):
		scripts = self.__scripts[script_type]['scripts']
		for pattern in scripts:
			if not lookup_path.startswith(pattern): # <-- [1]
				continue

			filepath = scripts[pattern]
			if isinstance(filepath, tuple):
				filepath = filepath[0]

			path = filepath + lookup_path[len(pattern) :] # <-- [2]

			if not os.path.isfile(path):
				continue

			log.debug('Serving path: %s', path)
			mime_type = mimetypes.guess_type(path) # <-- [4]

			request.setHeader(b'content-type', mime_type[0].encode()) # <-- [5]
			with open(path, 'rb') as _file: # <-- [3]
				data = _file.read()
			return data

The /js endpoint of the WebUI component didn’t require authentication, since its purpose is to serve JavaScript files for the UI. The request.lookup_path was validated to start with a known keyword [1], but it could have been bypassed with /js/known_keyword/../... The path traversal happened in [2], when the path was concatenated and later used to read a file [3]. The only limitation was the mimetypes.guess_type call at [4], because, in case it returned a mime type None, request.setHeader at [5] throws an exception.

The path traversal allowed for unauthenticated read of any file on the system as long as its MIME type was recognized.

Even if attackers constrain themselves to Deluge-only files, Deluge uses files with .conf extensions to store configuration settings with sensitive information. This extension is identified as text/plain by mimetypes.guess_type. A request to /js/deluge-all%2F..%2F..%2F..%2F..%2F..%2F..%2F.config%2Fdeluge%2Fweb.conf, for example, would return such information as the WebUI admin password SHA1 with salt and a list of sessions. The sessions are written to the file only on service shutdown, and, after the default 1 hour expiration, are not updated. But with some luck, attackers could find a valid session there to authenticate themselves to the service. Otherwise, they would need to brute force the password hash. Since Deluge doesn’t use a slow password hashing algorithm, they could do it very quickly for simple or short passwords.

Once attackers obtain an authenticated session, they could use the exploitation technique from CVE-2017-7178 to download, install, and run a malicious plugin on the vulnerable machine by using the /json endpoint Web API.

Exploiting it

If Deluge WebUI is hosted externally, the exploitation would be straightforward. However, even if the service is accessible only locally, since it is an unauthenticated endpoint, attackers could use a DNS rebinding attack to access the service from a specially crafted web site. For browsers that implement CORS-RFC1918, which segments address ranges into different address spaces (loopback, local network, and public network addresses), attackers could use a known Linux and MacOS bypass—the non-routable 0.0.0.0 IP address—to access the local service.

For the sake of simplicity, let’s assume attackers know the port of the vulnerable application (8112 by default for Deluge WebUI), though discovering that the port can be automated with Singularity. A Deluge WebUI user opens a web page with multiple IFrames by visiting the malicious somesite.com. Each frame fetches http://sub.somesite.com:8182/attack.html. In order to bypass SOP, the port number must be the same as the attacked application. The DNS resolver the attackers control may respond alternately with 0.0.0.0, and the real IP address of the server with a very low time to live (TTL). When the DNS resolves with the real IP address, the browser fetches a page with a script that waits for the DNS entry to expire by checking if they can request and read http://sub.somesite.com:8182/js/deluge-all/..%2F..%2F..%2F..%2F..%2F..%2F.config%2Fdeluge%2Fweb.conf. If the attack succeeds, the script will have exfiltrated the configuration file.

For the full source of attack.html please check this advisory.

How to proactively protect yourself from DNS attacks

• DNS rebinding doesn’t work for HTTPS services. Once a transport layer security (TLS) session is established with somesite.com, the browser validates the subject of the certificate against the domain. After the IP address changes, the browser needs to establish a new session, but it will fail, because the certificate of the locally deployed web application won’t match the domain name.
• As already mentioned, the authentication cookies for somesite.com won’t be accepted by the locally deployed web application. So be sure to use strong authentication, even if it is over unencrypted HTTP.
• Check the Host header of the request and deny if it doesn’t strictly match an allow list of expected values. A rebounded request will contain the host somesite.com header value.

Take this with you

Running web applications locally is a common practice by developers. However, a permanently deployed local network web application that doesn’t require authentication and TLS (i.e. no HTTPS encryption) is a red flag. DNS rebinding attacks are a vivid example of how seemingly isolated local services can be exposed through browser behavior and weak network assumptions.

Never assume a service is safe just because it’s “only running locally.” Always enforce strong, password-based authentication—even for internal services or development tools. Any local service without rigorous access control may be exposed through a victim’s browser. Validate the Host header. Use HTTPS wherever possible. 

DNS rebinding demonstrates that assumptions about network boundaries and browser security can be dangerously misleading. Be sure to include DNS rebinding into your threat model when developing your next web application. 

The post DNS rebinding attacks explained: The lookup is coming from inside the house! appeared first on The GitHub Blog.

We get it: you’d rather spend your time shipping features than chasing security alerts. That’s why we’ve built tools like Copilot Autofix directly into pull requests, enabling teams to remediate security issues up to 60% faster, significantly reducing Mean Time to Remediation (MTTR) compared to manual fixes. Autofix helps you catch vulnerabilities before they ever make it into production, so you spend less time fixing bugs and more time coding.

But what about the vulnerabilities already lurking in your existing code? Every unresolved security finding adds to your security debt—a growing risk you can’t afford to ignore. In fact, our data shows that teams typically address only 10% of their security debt, leaving 90% of vulnerabilities unprioritized and unresolved.

Our data shows that security debt is the biggest unaddressed risk that customers face: historically, only 10% of lingering security debt in merged code gets addressed, meaning until today, 90% of risks did not get prioritized. Now, our data shows that 55% of security debt included in security campaigns is fixed.

Security campaigns bridge this gap by bringing security experts and developers together, streamlining the vulnerability remediation process right within your workflow, and at scale. Using Copilot Autofix to generate code suggestions for up to 1,000 code scanning alerts at a time, security campaigns help security teams take care of triage and prioritization, while you can quickly resolve issues using Autofix—without breaking your development momentum.

Security campaigns in action

Since security campaigns were launched in public preview at GitHub Universe last year, we have seen organizations at all different stages of their security journey try them out. Whether they’ve been used to reduce security debt across an entire organization or to target alerts in critical repositories, security campaigns have delivered value for both developers and security teams in their efforts to tackle security debt.

In a sample of early customers, we found that 55% of alerts included in security campaigns were fixed, compared to around only 10% of security debt outside security campaigns, a 5.5x improvement. This shows that when alerts are included in a campaign, you can spend more time fixing the security debt, since the prioritization of which alerts to work on has already been taken care of by your security team. In fact, our data shows that alerts in campaigns get roughly twice as much developer engagement than those outside of campaigns.

Security campaigns: how they work

Triaging and prioritizing security problems already present in a codebase has to happen as part of the normal software development lifecycle. Unfortunately, when product teams are under pressure to ship faster, they often don’t have enough time to dig through their security alerts to decide which ones to address first. Luckily, in most software organizations, there is already a group of people who are experts in understanding these risks: the security team. With security campaigns, we play to the different strengths of developers and security teams in a new collaborative approach to addressing security debt.

1. Security teams prioritize which risks need to be addressed across their repositories in a security campaign. Security campaigns come with predefined templates based on commonly used themes (such as the MITRE top 10 known exploited vulnerabilities) to help scope the campaign. GitHub’s security overview also provides statistics and metrics summarizing the overall risk landscape.
2. Once the campaign alerts are selected and a timeline is specified, the campaign is communicated to any developers who are impacted by the campaign. The work defined in a campaign is brought to developers where they work on GitHub, so that it can be planned and managed just like any other feature work.

   

3. Copilot Autofix immediately starts suggesting automatic remediations for all alerts in a campaign, as well as custom help text to explain the problems. Fixing an alert becomes as easy as reviewing a diff and creating a pull request.

Crucially, security campaigns are not just lists of alerts. Alongside the alerts, campaigns are complemented with notifications to ensure that developers are aware of which alert they (or their team) are responsible for. To foster stronger collaboration between developers and the security team, campaigns also have an appointed manager to oversee the campaign progress and be on hand to assist developers. And of course: security managers have an organization-level view on GitHub to track progress and collaborate with developers as needed.

Starting today, you can also access several new features to plan and manage campaign-related work more effectively:

• Draft security campaigns: security managers can now iterate on the scope of campaigns and save them as draft campaigns before making them available to developers. With draft campaigns, security managers can ensure that the highest priority alerts are included before the work goes live.
• Automated GitHub Issues: security managers can optionally create GitHub Issues in repositories that have alerts included in the campaign. These issues are created and updated automatically as the campaign progresses and can be used by teams to track, manage and discuss campaign-related work.
• Organization-level security campaign statistics: security managers can now view aggregated statistics showing the progress across all currently-active and past campaigns.

For more information about using security campaigns, see About security campaigns in the GitHub documentation.

The post Found means fixed: Reduce security debt at scale with GitHub security campaigns appeared first on The GitHub Blog.

At GitHub Security Lab, one of the most common vulnerability types we find relates to the cross-origin resource sharing (CORS) mechanism. CORS allows a server to instruct a browser to permit loading resources from specified origins other than its own, such as a different domain or port.

Many developers change their CORS rules because users want to connect to third party sites, such as payment or social media sites. However, developers often don’t fully understand the dangers of changing the same-origin policy, and they use unnecessarily broad rules or faulty logic to prevent users from filing further issues.

In this blog post, we’ll examine some case studies of how a broad or faulty CORS policy led to dangerous vulnerabilities in open source software. We’ll also discuss DNS rebinding, an attack with similar effects to a CORS misconfiguration that’s not as well known among developers.

What is CORS and how does it work?

CORS is a way to allow websites to communicate with each other directly by bypassing the same-origin policy, a security measure that restricts websites from making requests to a different domain than the one that served the web page. Understanding the Access-Control-Allow-Origin and Access-Control-Allow-Credentials response headers is crucial for correct and secure CORS implementation.

Access-Control-Allow-Origin is the list of origins that are allowed to make cross site requests and read the response from the webserver. If the Access-Control-Allow-Credentials header is set, the browser is also allowed to send credentials (cookies, http authentication) if the origin requests it. Some requests are considered simple requests and do not need a CORS header in order to be sent cross-site. This includes the GET, POST, and HEAD requests with content types restricted to application/x-www-form-urlencoded, multipart/form-data, and text/plain. When a third-party website needs access to account data from your website, adding a concise CORS policy is often one of the best ways to facilitate such communication.

To implement CORS, developers can either manually set the Access-Control-Allow-Origin header, or they can utilize a CORS framework, such as RSCors, that will do it for them. If you choose to use a framework, make sure to read the documentation—don’t assume the framework is safe by default. For example, if you tell the CORS library you choose to reflect all origins, does it send back the response with a blanket pattern matching star (*) or a response with the actual domain name (e.g., stripe.com)?

Alternatively, you can create a custom function or middleware that checks the origin to see whether or not to send the Access-Control-Allow-Origin header. The problem is, you can make some security mistakes when rolling your own code that well-known libraries usually mitigate.

Common mistakes when implementing CORS

For example, when comparing the origin header with the allowed list of domains, developers may use the string comparison function equivalents of startsWith, exactMatch, and endsWith functions for their language of choice. The safest function is exactMatch where the domain must match the allow list exactly. However, what if payment.stripe.com wants to make a request to our backend instead of stripe.com? To get around this, we’d have to add every subdomain to the allow list. This would inevitably cause users frustration when third-party websites change their APIs.

Alternatively, we can use the endsWith function. If we want connections from Stripe, let’s just add stripe.com to the allowlist and use endsWith to validate and call it a day. Not so fast, since the domain attackerstripe.com is now also valid. We can tell the user to only add full urls to the allowlist, such as https://stripe.com, but then we have the same problem as exactMatch.

We occasionally see developers using the startsWith function in order to validate domains. This also doesn’t work. If the allowlist includes https://stripe.com then we can just do https://stripe.com.attacker.com.

For any origin with subdomains, we must use .stripe.com (notice the extra period) in order to ensure that we are looking at a subdomain. If we combine exactMatch for second level domains and endsWith for subdomains, we can make a secure validator for cross site requests.

Lastly, there’s one edge case found in CORS: the null origin should never be added to allowed domains. The null origin can be hardcoded into the code or added by the user to the allowlist, and it’s used when requests come from a file or from a privacy-sensitive context, such as a redirect. However, it can also come from a sandboxed iframe, which an attacker can include in their website. For more practice attacking a website with null origin, check out this CORS vulnerability with trusted null origin exercise in the Portswigger Security Academy.

How can attackers exploit a CORS misconfiguration?

CORS issues allow an attacker to make actions on behalf of the user when a web application uses cookies (with SameSite None) or HTTP basic authentication, since the browser must send those requests with the required authentication.

Fortunately for users, Chrome has defaulted cookies with no Samesite to SameSite Lax, which has made CORS misconfiguration useless in most scenarios. However, Firefox and Safari are still vulnerable to these issues using bypass techniques found by PTSecurity, whose research we highly recommend reading for knowing how someone can exploit CORS issues.

What impact can a CORS misconfiguration have?

CORS issues can give a user the power of an administrator of a web application, so the usefulness depends on the application. In many cases, administrators have the ability to execute scripts or binaries on the server’s host. These relaxed security restrictions allow attackers to get remote code execution (RCE) capabilities on the server host by convincing administrators to visit an attacker-owned website.

CORS issues can also be chained with other vulnerabilities to increase their impact. Since an attacker now has the permissions of an administrator, they are able to access a broader range of services and activities, making it more likely they’ll find something vulnerable. Attackers often focus on vulnerabilities that affect the host system, such as arbitrary file write or RCE.

Real-world examples

A CORS misconfiguration allows for RCE

Cognita is a Python project that allows users to test the retrieval-augmented generation (RAG) ability of LLM models. If we look at how it used to call the FastAPI CORS middleware, we can see it used an unsafe default setting, with allow_origins set to all and allow_credentials set to true. Usually if the browser receives Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true, the browser knows not to send credentials with the origin, since the application did not reflect the actual domain, just a wildcard.

app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

However, FastAPI CORS middleware is unsafe by default and setting these two headers like this resulted in the origin being reflected along with credentials.

Currently, Cognita does not have authentication, but if its developers implemented authentication without fixing the CORS policy, their authentication could be bypassed. As it stands, any website can send arbitrary requests to any endpoint in Cognita, as long as they know how to access it. Due to its lack of authentication, Cognita appears intended to be hosted on intranets or locally. An attacking website can try guessing the local IP of a Cognita instance by sending requests to local addresses such as localhost, or it can enumerate the internal IP address space by continually making requests until it finds the Cognita instance. With this bug alone, our access is limited to just using the RAG endpoints and possibly deleting data. We want to get a foothold in the network. Let’s look for a real primitive.

We found a simple arbitrary file write primitive; the developers added an endpoint for Docker without considering file sanitization, and now we can write to any file we want. The file.filename is controlled by the request and os.path.join resolves the “..”, allowing file_path to be fully controlled.

@router.post("/upload-to-local-directory")
async def upload_to_docker_directory(
    upload_name: str = Form(
        default_factory=lambda: str(uuid.uuid4()), regex=r"^[a-z][a-z0-9-]*$"
    ),
    files: List[UploadFile] = File(...),
):
...
        for file in files:
            logger.info(f"Copying file: {file.filename}, to folder: {folder_path}")
            file_path = os.path.join(folder_path, file.filename)
            with open(file_path, "wb") as f:
                f.write(file.file.read())

Now that we have an arbitrary file write target, what should we target to get RCE? This endpoint is for Docker users and the Cognita documentation only shows how to install via Docker. Let’s take a look at that Dockerfile.

command: -c "set -e; prisma db push --schema ./backend/database/schema.prisma && uvicorn --host 0.0.0.0 --port 8000 backend.server.app:app --reload"

Looking carefully, there’s the --reload when starting up the backend server. So we can overwrite any file in the server and uvicorn will automatically restart the server to apply changes. Thanks uvicorn! Let’s target the init.py files that are run on start, and now we have RCE on the Cognita instance. We can use this to read data from Cognita, or use it as a starting point on the network and attempt to connect to other vulnerable devices from there.

Logic issues lead to credit card charges and backdoor access

Next, let’s look at some additional real life examples of faulty CORS logic.

We found the following code was found on the website https://tamagui.dev. Since the source code is found on GitHub, we decided to take a quick look. (Note: The found vulnerability has since been reported by our team and fixed by the developer.)

export function setupCors(req: NextApiRequest, res: NextApiResponse) {
  const origin = req.headers.origin

  if (
    typeof origin === 'string' &&
    (origin.endsWith('tamagui.dev') ||
      origin.endsWith('localhost:1421') ||
      origin.endsWith('stripe.com'))
  ) {
    res.setHeader('Access-Control-Allow-Origin', origin)
    res.setHeader('Access-Control-Allow-Credentials', 'true')
  }
}

As you can see, the developer added hardcoded endpoints. Taking a guess, the developer most likely used Stripe for payment, localhost for local development and tamagui.dev for subdomain access or to deal with https issues. In short, it looks like the developer added allowed domains as they became needed.

As we know, using endsWith is insufficient and an attacker may be able to create a domain that fulfills those qualities. Depending on the tamagui.dev account’s permissions, an attacker could perform a range of actions on behalf of the user, such as potentially buying products on the website by charging their credit card.

Lastly, some projects don’t prioritize security and developers are simply writing the code to work. For example, the following project used the HasPrefix and Contains functions to check the origin, which is easily exploitable. Using this vulnerability, we can trick an administrator to click on a specific link (let’s say https://localhost.attacker.com), and use the user-add endpoint to install a backdoor account in the application.

func CorsFilter(ctx *context.Context) {
    origin := ctx.Input.Header(headerOrigin)
    originConf := conf.GetConfigString("origin")
    originHostname := getHostname(origin)
    host := removePort(ctx.Request.Host)

    if strings.HasPrefix(origin, "http://localhost") || strings.HasPrefix(origin, "https://localhost") || strings.HasPrefix(origin, "http://127.0.0.1") || strings.HasPrefix(origin, "http://casdoor-app") || strings.Contains(origin, ".chromiumapp.org") {
        setCorsHeaders(ctx, origin)
        return
    }

func setCorsHeaders(ctx *context.Context, origin string) {
    ctx.Output.Header(headerAllowOrigin, origin)
    ctx.Output.Header(headerAllowMethods, "POST, GET, OPTIONS, DELETE")
    ctx.Output.Header(headerAllowHeaders, "Content-Type, Authorization")
    ctx.Output.Header(headerAllowCredentials, "true")

    if ctx.Input.Method() == "OPTIONS" {
        ctx.ResponseWriter.WriteHeader(http.StatusOK)
    }
}

DNS rebinding

DNS rebinding has the same mechanism as a CORS misconfiguration, but its ability is limited. DNS rebinding does not require a misconfiguration or bug on the part of the developer or user. Rather, it’s an attack on how the DNS system works.

Both CORS and DNS rebinding vulnerabilities facilitate requests to API endpoints from unintended origins. First, an attacker lures the victim’s browser to a domain that serves malicious javascript. The malicious javascript makes a request to a host that the attacker controls, and sets the DNS records to redirect the browser to a local address. With control over the resolving DNS server, the attacker can change the IP address of the domain and its subdomains in order to get the browser to connect to various IP addresses. The malicious javascript will scan for open connections and send their malicious payload requests to them.

This attack is very easy to set up using NCCGroup’s singularity tool. Under the payloads folder, you can view the scripts that interact with singularity and even add your own script to tell singularity how to send requests and respond.

Fortunately, DNS rebinding is very easy to mitigate as it cannot contain cookies, so adding simple authentication for all sensitive and critical endpoints will prevent this attack. Since the browser thinks it is contacting the attacker domain, it would send any cookies from the attacker domain, not those from the actual web application, and authorization would fail.

If you don’t want to add authentication for a simple application, then you should check that the host header matches an approved host name or a local name. Unfortunately, many newly created AI projects currently proliferating do not have any of these security protections built in, making any data on those web applications possibly retrievable and any vulnerability remotely exploitable.

   public boolean isValidHost(String host) {

        // Allow loopback IPv4 and IPv6 addresses, as well as localhost
        if (LOOPBACK_PATTERN.matcher(host).find()) {
            return true;
        }

        // Strip port from hostname - for IPv6 addresses, if
        // they end with a bracket, then there is no port
        int index = host.lastIndexOf(':');
        if (index > 0 && !host.endsWith("]")) {
            host = host.substring(0, index);
        }

        // Strip brackets from IPv6 addresses
        if (host.startsWith("[") && host.endsWith("]")) {
            host = host.substring(1, host.length() - 2);
        }

        // Allow only if stripped hostname matches expected hostname
        return expectedHost.equalsIgnoreCase(host);
    }

Because DNS rebinding requires certain parameters to be effective, it is not caught by security scanners for the fear of many false positives. At GitHub, our DNS rebinding reports to maintainers commonly go unfixed due to the unusual nature of this attack, and we see that only the most popular repos have checks in place.

When publishing software that holds security critical information or takes privileged actions, we strongly encourage developers to write code that checks that the origin header matches the host or an allowlist.

Conclusion

Using CORS to bypass the same-origin policy has always led to common mistakes. Finding and fixing these issues is relatively simple once you understand CORS mechanics. New and improving browser protections have mitigated some of the risk and may eliminate this bug class altogether in the future. Oftentimes, finding CORS issues is as simple as searching for “CORS” or Access-Control-Allow-Origin in the code to see if any insecure presets or logic are used.

Check out the Mozilla Developer Network CORS page if you wish to become better acquainted with how CORS works and the config you choose when using a CORS framework.

If you’re building an application without authentication that utilizes critical functionality, remember to check the Host header as an extra security measure.

Finally, GitHub Code Security can help you secure your project by detecting and suggesting a fix for bugs such as CORS misconfiguration!

The post Localhost dangers: CORS and DNS rebinding appeared first on The GitHub Blog.