I have an application that unshortens URLs by using the python requests library to send HEAD requests with allow_redirects=True. I don't do anything with the response except check the response URL. Since the URLs are provided by users, is there a risk of the production machine being compromised by a malicious server?

  • Unless you are eval'ing the response or there is some unknown vulnerability in requests, I would imagine no. Commented Oct 25, 2019 at 14:56

2 Answers 2


You're providing a tool for outside attackers to probe your internal network. By specifying different hostnames or IP addresses and different ports, an attacker can enumerate the portion of your network that is invisible to them. Even if you don't return any actual information that distinguishes between "there's nothing there", "there's a machine at that address but it doesn't listen on that port", and "there's a machine at that address listening on that port, but it doesn't speak HTTP", an attacker might be able to figure out the difference from timing or other side channels. Additionally, if you have any internal web services (fairly likely) and they respond to any requests with redirects to other internal services, you will end up directly exposing those redirected-to internal addresses to the attackers.

Although the maximum impact of this kind of attack is fairly low in isolation, the information gathered can be quite valuable for future attacks. The more understanding an attacker has of your network topology and running services, the faster the attacker can pivot across your network to reach their target (source code, credentials, sensitive data, critical systems that a ransomware attack would really matter on, etc.) once they manage to breach some system on the periphery of your network. Since incident response is largely a matter of speed and you can never assume your periphery is fully secure, this could be the difference between "somebody breached our bastion host but we stopped them before they got anything sensitive" and being the next Equifax or Target or whatever.

You can, of course, mitigate this risk by filtering the requests to only external sites. It can be tricky, in a large company, to determine what is and is not external, though; what if somebody uses this to port scan your recent acquisition to whom you've added into your VPC but not yet updated your "external" list? Also, many companies have their own URL-shortening schemes, which would of course go to an internal service but which a user might reasonably want to unshorten.

EDIT: You're also adding a system that will serve attacker-controlled content to users. If a user sends a query to a malicious URL, and the server responds with a malicious redirect header, you will presumably return this value to the user. Depending on how the returned value is presented and what format it's in, you risk enabling attacks such as XSS or header injection. Obviously, there's ways to handle potentially-malicious user-supplied content (escape/encode output, and potentially also validate content as a defense-in-depth), just make sure you use them here.

  • Thank you, this is very helpful. This machine does not respond to external requests, so I think the risk of exposing an attack surface for future attacks is relatively low. I will make sure to carefully handle the data's eventual display.
    – Aqqles
    Commented Oct 25, 2019 at 20:55
  • It should be pretty safe if you only allow FQDNs in the user-supplied URLs, and no redirects.
    – forest
    Commented Oct 26, 2019 at 23:57
  • @forest Well, if you also have a filter that prohibits internal domains, maybe. It's not that hard to guess a corp's internal FQDNs, and some of them are widely known (* .*groupname*.corp.microsoft.com, for example). Another thing that might help is using software that only resolves names using an external name server; that would still let attackers probe the handful of foolish companies that publish their internal (and otherwise-unreachable) names to public DNS, but would help everybody else.
    – CBHacking
    Commented Oct 27, 2019 at 3:51

There's always a risk of compromise when accepting/parsing input submitted by users. This is the core of the web-based attacks like directory traversal, sql injection, etc. as well as more traditional attacks (e.g. buffer overflows).

This is all highly dependent on the web developer's ability (sounds like you) to limit the information submitted by the user to the information expected by the web page--escaping characters, ensuring only alphabet characters, etc. Additionally, this is also highly dependent on the web server software itself (apache, iis, nginx), the language being used (PHP, .NET, Perl, Python, Javascript) and any other accoutrements involved (e.g. Adobe, ActiveX, etc.).

Here is an example of something web PenTesters look for specifically with HEAD requests: https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)#Testing_for_HEAD_access_control_bypass

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .