Both malicious and curious users may attempt to manipulate URL strings to gain access to bypass access controls or the expected path through a website.
- A URL manipulation attack is when someone edits the URL text in the browser's location bar in order to probe a website. URLs are easily changed, and often follow a pattern, which makes them inviting targets. Manipulation may be performed by innocent users who are just curious, or by hackers who are probing for vulnerabilities. Editing a URL can reveal private information or allow users to perform actions which should be restricted. Manipulating a URL may reveal a private webpage. A public website may not have a link to the page, or the page may be only accessible under certain conditions. For example, adding preview=true to a URL might show an unpublished version of the page. URLs may correspond to a set of files and directories. Changing the URL can help to map their structure. Values in a database can also be mapped. If a page displays a person's contact information when the URL contains an ID of 27, then an attacker can try all IDs to get a full list of the people in that database. Software on a Web server sometimes includes built-in webpages with special information for administration. For example, wp-admin is a standard login page for WordPress websites, and its presence indicates that WordPress is being used. One of the most dangerous consequences of URL manipulation is for an attacker to be able to access privileged resources that they shouldn't be able to see or to use. This common vulnerability has a special name, insecure direct object reference, or IDOR for short. It's ranked as one of the top security threats. Insecure direct object reference is when code accesses a restricted resource based on user input, but fails to verify the user's authorization to access that resource. Put another way, there exists a direct reference to an object which is insecure. Imagine that a user who's not logged in clicks on this link to view an invoice after completing a purchase online. This is a direct object reference. A user has direct access to the invoice, which is the object, using the invoice ID. It's insecure if there's never any verification that the user is authorized to view that invoice. Not only could anyone use the same URL to access this invoice, but entering other invoice IDs, such as CR-29813, would most likely provide insecure access to other invoices. These invoices might reveal personal information, items ordered, and credit card numbers. Types of resources which could have insecure direct references are database data, files, directories, scripts, and functions. If a user can trigger what should be a privileged result without having to be logged in or having their access privileges checked, then it's an example of insecure direct object reference. You can prevent URL manipulation attacks and insecure direct object references. Remember, the URLs are exposed and easily editable. Pages on your website are accessible even if they're not linked to from other pages. Security through obscurity on its own is not enough. Consider edge cases and expect the unexpected. When possible, define an allow list of the acceptable parameters, and reject other input. If a list has a sort parameter which can be set to one of five values, then use an allow list and reject all other values. Configure the Web server to gracefully handle errors and unfound URLs. remember to keep error messages vague so that if a user is probing, they won't get helpful feedback. Most importantly, if you need to control access, then use access control. Validate a user's authorization before allowing access to a privileged resource. Require a user to log in and reconfirm that a logged-in user has enough access privileges. Another prevention strategy is to change the direct object reference to an indirect object reference. One way to do this would be to provide a user a list of choices which are specific to the current page. For example, a logged-in user might see a list of four previous orders that they've placed along with links which would let them see details. In the database, these orders might have IDs like 23, 47, 82, and 105. A direct object reference would use those ID numbers in the URL with the links. Instead, you could use numbers one through four for the URL and then write code which determines that order number two is order 47 in the database. Now the reference is indirect. The user can only ask for those four orders. A request for order five would not return anything. Being thoughtful about URLs, using access control when you need it, and using indirect object references when possible will help prevent URL manipulations and insecure direct object references.
- Threat models
- Least privilege
- Defense in depth
- Validating and sanitizing input
- Credential attacks
- SQL injection
- Cross-site scripting