Join Kevin Skoglund for an in-depth discussion in this video URL manipulation, part of Programming Foundations: Web Security.
In this movie, we'll talk about attacks that use URL manipulation. URL manipulation is a very simple concept but it's important that you don't underestimate the security problems that it can cause. It's dangerous precisely because it's so easy to execute. URL manipulation is simply editing the URL string in the browser's location bar to probe the website. It might be done out of curiosity, it can be someone testing the strength of the rules on your website, or it can be outright maliciousness. But it can be used for revealing private information, and it can be used for performing restricted actions.
Now, I'll confess to this one. I've done it. If your website offers me two things for free but wants me to give you my email address in order to view the third thing, I'm going to examine the URL of the first two and see if I can use that information to get the third one, without having to give up my info. Now, that's a relatively harmless example. Let's look at a few others. Let's say that you run an e-commerce website. And at the end of making a purchase from your website, I notice that the URL for the page that shows me my invoice includes my invoice number. All it takes is for me to get a little bit curious and wonder, well what happens if I change that number to another number? Will I see another invoice? For example if I typed in 1-7-3-9-0, would I see the invoice of the person who came right before me? If I did I might see what they purchased, I might see their billing information, and possibly even their credit card information.
Do you understand now why you shouldn't underestimate this attack? By just simply changing one character in a very visible part of my interaction with the website. I could potentially be able to see some very sensitive data. Let's say that as I log in, I notice that my user ID is put up in the URL string as I'm being authorized. I could try and manipulate that, and pick a different user ID, and see if I could authorize myself as being someone else. Or worse, if you put the session ID up in the URL string, maybe I can manipulate that session ID that's up there and try to hijack someone else's session.
We'll talk about session hijacking more in-depth later, but I could simply put another session ID in there, and become someone else. Or, maybe I just noticed that when I go to visit a products page that it says preview equals false. Naturally being curious I'm wondering, well, what happens if I change that to preview equals true? What will I see then? Maybe I'll see a version of the page that wasn't meant for the public, that's not quite ready for primetime. Or, maybe I'll see products that haven't been released yet, and there by divulge some sensitive business strategy.
Or maybe I look at a page and I click on an image and I notice that when I view the image that the URL for just that image is images/small/rockymtns.jpg. And I think well that's a nice image. I wish I had a large copy of that. Well I can change the word small to be large or extra-large or original. All sorts of words I could try in there to see what I can get back and see if I can find a larger version of this image. Or maybe if some of the images are water marked maybe I can try and find an image that's not yet been water marked by surfing through all of those.
Or maybe I simply just try and monkey around with the URL itself. I notice that the URL is reports, exports, sales, so I wonder what else can I export. Or maybe I just simply blindly attempt to type in some URLs to see if maybe I can export a sales report. Or if I know that I can export a sales report, maybe I try and see if I can export something else You get the idea. All I'm doing is simply manipulating these URL strings to try and get information that you didn't intend for me to have. So how do we prevent against it? Well, the first thing is just to realize that URLs are exposed and easily editable.
You should just be aware of that fact as you are developing. And that pages on your website can be accessible even if you don't link to them from other pages. So just because you've removed all the links to a page. If the page is still there and web server still willing to serve it up to the user. It's a variable via a deep link. A lot of times search engines will still hold on to those deep links for those pages. But even if it's never been visible to a search engine, it's still as accessible the user can guess the URL. So you shouldn't use obscurity of those kinds of pages for access control.
If you need access control, implement access control. Have usernames and passwords and enforce that strictly. You should also keep your error messages vague. We've talked about this before. The idea is that if a user is probing don't give them any feedback. Just tell them sorry, page not found. Don't need to tell them anything in addition to that, or tell them, you know, there is a server error and give them a generic 500 page. But if you give them any other information beyond that you might be helping them as they probe your site, looking for things that do work.
And the last one is to clarify your GET and POST requests. We've touched on this a couple of times. Your GET request should be idempotent, meaning that they don't make changes. Your POST request is what should be used for making changes. Now this doesn't solve the problem of URL manipulation on its own, but it does at least ensure that the POST requests can't be manipulated. And those typically are the most sensitive of the kind of requests that you have. Those are the ones that edit information in the database, the ones that make changes. The GET request still might allow them to be able to see information that they shouldn't see, but that's what we're going to use those other three techniques for.
If we use all of these, and especially if you're just conscious of the fact that URLs are always exposed and always editable, and you're thinking about that as you're developing. Then you'll be able to design sites where your own manipulation won't yield anything useful.
This course is great for developers who want to secure their client's websites, and for anyone else who wants to learn more about web security.
- Why security matters
- What is a hacker?
- How to write a security policy
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF)
- SQL injection
- Session hijacking and fixation
- Passwords and encryption
- Secure credit card payments