views:

60

answers:

1

first of all, the question from a naive point of view:

I've got a WebApplication with a URL to a product like Products?id=123. Let's say I've got an administration page reachable from Products?id=123&editable=true.

If I consider that no one will ever try to enable the editable parameter, and thus don't need any further security mechanism to protect this page, that's security by obscurity, and that's not a good idea, right?

-

In my real case problem, it's slightly more subtle: is there any danger in allowing anyone to know my administration URLS? for instance, while working with XSL, I would like to write:

<xsl:if test="/webAlbums/mode/@admin">
    (compute edit link)
</xsl:if>

but wouldn't it be easier for a potential attacker to find a weakness in 'important' pages?

+1  A: 

Security through obscurity is barely security at all. Don't count on it.

You should make an authentication system that prevents people from using the admin page through actual security.

As for people knowing your admin URLs, it should be fine as long as your admin page is protected and there is no sensitive data being shown in the URL (such as the internal representation of a data type, the internal ID of some data, etc).

Chetan
Remember that a password is also security through obscurity.
Gabe
@Gabe: Security through obscurity generally means that there are easy access paths to a system, but the designers are counting on the possibility that attackers won't find them. A password would actively protect these access paths so that even if they were found, they would be hard to break through.
Chetan
How is knowing the password not an "easy access path"?
Gabe
@Gabe: Because you don't just "stumble" across a password. Instead of counting on attackers to not happen to find an easy access path, you're preventing them from using it without actively trying to break it. It's the difference between hiding the door to your house in an overgrown bush and putting a troll in front of it to guard it.
Chetan
Assuming you don't have the secret URL on your web site (in a link or something), how would you "stumble across" it?
Gabe
@Gabe: I'll answer your question with a question. Would you feel secure with the only security to your house being that your front door is hidden behind an overgrown bush? Sure, people aren't likely to accidentally find it, but someone trying to steal from you most definitely will look for it. Similarly, attackers will look for hidden URLs to get more information or additional access points to your site that you haven't specifically protected.
Chetan
@Gabe: See this similar question for more details: http://stackoverflow.com/questions/533965/why-is-security-through-obscurity-a-bad-idea
Chetan
Chetan: The fundamental flaw in your analogy is that my house has a finite (and quite small) perimiter, making it trivial to exhaustively search. URL space is infinite, or at least large enough to not be able to search exhaustively. If you keep your URL as secure as your password, there's no reason it won't be as secure.
Gabe
@Gabe: You're right, the analogy isn't as great as I hoped it would be. But attackers wouldn't do an exhaustive search of the URL search space - there are easier ways of finding hidden URLs, at least easier than breaking a good password scheme.
Chetan
Chetan: How are you going to *find* a hidden URL? Obviously having a URL of `/admin` is insecure, but so is having `admin` for a password. If his admin URL is `/webAlbums/mode/@admin/jOGT(940jw(4$(*` would you say that it's less secure than having `jOGT(940jw(4$(*` for a password?
Gabe
@Gabe: Well, I would say `/webAlbums/mode/@admin/jOGT(940jw(4$(*` is a form of password protection, whereas `/webAlbums/mode/@admin` is security through obscurity. It doesn't matter as much what the definition is - the fact is that you don't want to have `admin` for a password; it's a weak form of security and it's something attackers are likely to try first.
Chetan
Chetan: That's my point exactly. The only difference between a password and a URL is where the user enters it. An easy-to-guess URL is no worse than an easy-to-guess password, and a hard-to-guess URL is just as good as a hard-to-guess password.
Gabe
@Gabe: I think we're getting hung up on definitions. Security through obscurity has a pretty general definition, so it's easy to compare it to a weak password. The main point is that security through obscurity is as bad as a really weak password, so you can't rely on it alone.
Chetan
@Gabe and @Chetan: I think you're both missing the point that passwords are *never* sent across the wire in the clear (at least, they should never be sent in the clear), whereas URLs most certainly are in cleartext. A password is a defined secret with proper storage and disclosure rules (hash and don't, respectively) whereas a URL is public information in the sense that it is not a defined secret.
Cameron Skinner
Cameron: I think your definition of *never* is vastly different from mine. How do you make a web site's passwords *not* get sent in the clear?
Gabe
@Cameron: Ah, I forgot that point. +1 to you.
Chetan
@Gabe: https will encrypt the whole transport layer ensuring passwords are not sent in the clear. Note that it will *not* encrypt the URL.
Cameron Skinner
Cameron: What makes you think HTTPS can encrypt the whole transport layer but somehow manage to avoid encrytping the URL?
Gabe
Fair point, https does encrypt the URL too. I stand corrected. Nevertheless, I stand by my definition of "never", assuming the developer isn't stupid enough to not use https when passwords are involved.
Cameron Skinner