| « Prev | Page 1 | Next » |
|
I'm sure there must have been a perfectly logical reason for this at the time, damned if I know what it is though.
|
|
"Taking over the administration of a web site..." is always a scary thought.
This is classic self-assuring security. It appears (to the coder at the time) to be a great scheme for keeping the site safe. Unfortunately, not enough coders think like hackers. |
|
Guid "authentication", the latest trend in security.
|
|
How come he/she felt the need to break the string over multiple lines? It's not like anyone's going to be debugging it! I like to just tuck that kind of thing away off the side of the screen.
|
80-column terminals! |
|
I don't see the problem. These ids surely look random enough. The developer has successfully managed to avoid the problem of weak passwords!
On a more serious note, this is stupid but not necessarily a wide-open security flaw. If these "random" "ids" are present only in links on administrative pages, then in order to find them out, you must already know an "id" (otherwise you get Access Denied). Isn't it more or less equivalent to guessing admin's password in a normal system? |
|
No it isn't like that. Otherwise it wouldn't be on this site. You see?
CAPTCHA = IAMAROBOT |
Yeah, I don't think security is the biggest issue here, but it's a very twisted perception of the concept of "random", as the title suggests, and maintenance of the backoffice system sure must be a drag, having to copy these strings everywhere in all links. 
|
|
Most likely the coder wanted it to be random, but then just couldn't figure out how to make that work.
|
|
One thing here is that it's impossible to have different tiers of administration. Anyone in the interface can do anything, I assume. Even if it checks the username for an access level, with the same ids used everywhere it would be trivial for someone who has partial access to the interface to get full access if they know the head administrator's username.
I'm guessing a password isn't checked, otherwise the randomids are more pointless than a WTF. The problem with this is eventually one of the following will happen: 1) Someone will post a screenshot of the admin interface to show someone something. If they forget to block out the randomid, or assume it's just for them and won't work for others (a reasonable assumption, imo), we have a problem. Although the ids are long enough that it probably wouldn't be entirely compromised by a single screenshot. 2) Someone will save the HTML source of a page somewhere to show someone something, or to remind themselves of some information therein. With all the randomids in the HTML file intact. 3) Anyone with access to the source code can have full administrative access to the application as well (in a perfect world, all apps would be designed so that even if the source code is widespread, the app can't be cracked... usually because the passwords are hashed and stored in a DB somewhere). 4) Someone will post a link to an administrative page publicly (ie administrator A showing administrator B where particular functionality is), assuming only those with the proper access rights can access it, except anyone can use the link and gain full administrative access. Granted, administrators could be explicitly instructed to make sure randomids are never posted publicly, but that's only a band-aid over a wound that needs stitches. Plus there's one last problem in which the annoying fix would probably be neglected by users: 5) BROWSER HISTORY |
|
It's amazing to me how many people don't know about .htaccess. I've added that to the list of questions I interview people with.
|
Re: My Kind of Random
2007-06-01 10:11
•
by
Burgz
(unregistered)
|
|
.htaccess = bad, session + MySQL = good.
captcha = doom |
Re: My Kind of Random
2007-06-01 10:14
•
by
Mitch
(unregistered)
|
my point is they aren't attempting to create any access control lists here. Just permission = yes or permission = no that's why .htaccess. I shudder to think what this person's session vars would look like. |
Re: My Kind of Random
2007-06-01 10:46
•
by
Matthew
(unregistered)
|
It probably is a random string. I just wasn't dynamic. So it was generate-once-use-many. |
|
Um... ever heard of output_add_rewrite_var?
|
You've beat me with the XKCD reference :) |
Re: My Kind of Random
2007-06-01 11:28
•
by
Iain Collins
(unregistered)
|
Actually, .htaccess is not bad, any more than/etc/passwd is bad. Using LDAP, Net Info or Active Directory or PAM is more sophisticated than using plain old /etc/passwd and a shadow file for login authentication, but it's not always warrented or the right thing to do - the same thing applies to SQL v htaccess. There are times when you are writing something and don't happen to be using an SQL DB already (or at least not one suitable for storing session data in). Maybe you are instead talking to an LDAP DB, or a number of other backend XML interfaces, or a remote SQL database where have only read access. In that sort of instance, if you are only implimeting a few accounts (say between 1 and few hundred users), your service is going to be a lot more robust if you don't rely on an unnecessary additional point of failure like an SQL DB. In addition you may have an NFS or SAN share (or snapmirror/rsync setup to mirror content geographically distanct hosts) that allows you to propagate an .htaccess file to multiple hosts. There are plenty of great libraries for managing .htaccess and .htgroup files (and it's pretty trivial too) in a range of lanauges, so it's very easy to create and manage them (and of course the format itself is very simple). You can even use info fields to store user data, like an email address for automatic password re-sets. |
|
That should be automated password resets (as fun as automatic password resets are ;-).
Captcha: muhahaha |
Oh, really? Geez, I could swear we were seeing this because someone was trying to debug it, or at least to understand what is going on in case of future need for debugging.
So how does the maintainer know that all the line contains is the key-babble? Code that is not visible is probably the code containing the bug. Whatever may be wrong with generating security keys in HTML or JS source, I give a big thumbs up to the choice of formatting here. I just wish more developers were aware of the proper use of concatenation operators. There would be a lot less WTF code to see here, I suspect. |
|
Someone remind me what "developmestuction" means? That has to be the worst neologism ever. I can barely figure out how to pronounce it, let alone what it's trying to convey.
|
It basically means FUBAR; sites up with random page naming, test pages alongside production, admin=false as "security", cryptic code, etc. http://worsethanfailure.com/Articles/The_Developmestuction_Environment.aspx |
|
Ah yes, that's the article. And still, a horrible word. Looks like someone typoed "developmestruction" (development + destruction, whee!").
|
|
Is it me, or does "copying a random string" sound like an oxymoron?
|
Re: My Kind of Random
2007-06-01 14:43
•
by
w00t
(unregistered)
|
Using plain old .htaccess usually implies using plain old Basic Authentication. Just a quick update; Basic Authentication sends the password, in plaintext (well, base-64, but that's just an encoding), in the header of each request, until you close the browser. There's not even a logout button. If you use some sort of session, you can simply ignore sessioncookies that are too old; if someone snoops part of a session after having logged in, even if the password was sent in plaintext during the login procedure, they can only get access to the current session (which they already have by virtue of snooping anyway). There's of course a better solution, digest authentication, which uses an MD5 of the password and a nonce - but the downside to that is that an MD5 hash is made on every request. Also, there's still no logout button. It's much better for performance to just establish a session using a cookie. |
Better yet is a combination. Store passwords only as hashes, match on initial login and issue a ticket with server-side matching. Send the ticket to a page that does nothing but re-authenticate based on the ticket rather than password, and start the interactive session once logged in with the ticket, which can be updated with each request to keep the session current. I prefer to use hidden form fields, rather than cookies, though. That way, you can set an extremely short [30 seconds-2 minutes] timeout on the initial login, to prevent refresh exploits, while allowing for a longer timeout during the interactive session. |
Re: My Kind of Random
2007-06-01 16:18
•
by
alkhimey
(unregistered)
|
|
xkcd is one of the best web comics.
|
|
They could have at LEAST used constants in an include file to make the links easy to maintain. Unbelievable.
|
I used to agree with this philosophy until I spent two days trying to figure out why one of the fields of a struct was simply nonexistent even though I could plainly see it in the source code. It turns out that each member of the struct had a long comment after it /* old school */ C-style. The comments were long and very descriptive, but ran far off the edge of my text editor's screen. Can you smell the WTF yet? The comment on the field before my missing field was not closed, making the missing field become part of the comment...sigh. I didn't figure this out until I printed out the code. There is something to be said for keeping the code on the screen. Or maybe for using // instead of /* */. |
|
Another concern is that if a user USED to be an adminstrator, and has since been demoted, his shortcuts to the admin pages could still work.
|
Re: My Kind of Random
2007-06-01 19:22
•
by
Ornedan
(unregistered)
|
A syntax highlighting editor might also help. Despite what some might say, Real Programmers(TM) don't use Notepad. |
Except that a) There is no way to remove someone from the access list. Once they have access the only way to kick them out is to rewrite the application. b) If someone were to copy and paste a URL and send it to someone, they could unknowingly give admin access to the site. c) Its written in PHP. d) Access is stored on any computer the site is accessed from in the browser history. e) Everything else that is horribly wrong with this system. |
Or maybe using an editor that implements at least rudamentary syntax highlighting...? Anything else could pretty much be considered a WTF (in the old sense) in itself. |
Get a BIGGER screen! |
|
Well, I believe that this GUID serves as a ticket.
The concept of a ticket is used to make it harder for a malicious forum user to force an administrator that has RememberMe checked, to visit <img src=admin_panel.php?action=give_user_the_power&user=17>. So you simply combine the tickets, with any favorite authentication and authorization method, to make sure, that if somebody issues any action in admin_panel.php, she is: 1. authenticated (for example by RemeberMe coockie - which is bad:P) 2. authorized (for example by checking in SQL) 3. has visited the site by consciously clicking a link, or (preferably) by POSTing a form What is realy bad here, is that the GUID was copy&pasted all over the place, instead of being either generated (preferably from user-related data and a validity time span), or being made a global constant |
So you have a color printer, but a black-and-white screen? |
Re: My Kind of Random
2007-06-04 04:41
•
by
Anonymous Tart
(unregistered)
|
.htaccess == bad , httpd.conf == good Enabling .htaccess requires apache to try to open a .htaccess in every directory from the depth that your file is at to the root, and merging the results. Anything you want to specify in a .htaccess can be specified in a <Location> or <Directory> directive. Its amazing to me how many people dont know that. I've added that to the list of questions I interview people with. Fools. PS Theres f all wrong with BasicAuth, serve with TLS. |
Re: My Kind of Random
2007-06-04 07:29
•
by
Comanche
(unregistered)
|
It's even more amazing to me how many people mistakenly associate .htaccess files exclusively to password protection / authentication. .htaccess files are a means to configure the HTTPd server when you don't have access to the main configuration. Proper comment would've been "It's amazing to me how many people don't know about Allow/Deny/Require/Satisfy." I've added you to the list of people I wouldn't hire. |
You're understating it. I'm a big fan of joel on software, and he's quoted various metrics before about how productivity and efficiency vary with whether a piece of code fits on a single screen. For instance, two functions that are each one screen long are more easily understood and less likely to be buggy than a single method that is two screen lengths. He also buys his developers big screens so that they are more likely to view a piece of code in a single screen. |
If you're using vi (and not vim, which doesn't exist in many places), I'd be really surprised to see you using color cues. |
Re: My Kind of Random
2007-06-04 11:36
•
by
Iain Collins
(unregistered)
|
To address those two issues: Just as with other protocols like POP, IMAP and SMTP AUTH, authentication over HTTP with Basic Auth involves details being sent encrypted if you using SSL, but sent in clear text only if you are not, and applies whether you are using Basic Auth or an HTTP POST to send the username/password pair. (As you rightly say, .htaccess does imply the use of Basic Auth, but of course you don't have to be using Basic Auth with an .htaccess file, you could be handling that in your application.) Regarding providing a logout button, - you can actually provide a logout button even with Basic Authentication. IIRC there are two ways to do this. For example, you can generate a cookie with a random string and using that string as the realm you request when prompting (and subsequently verifying) client credentials. By creating a button (powered by Javascript or CGI) that changes the contents of the cookie, you change the realm (causing the current auth credentials being supplied by the client to be rejected - and requring them to be re-entered again if the user tries to re-enter a protected area of the site). (The other method I've kludged did something odd to fool the client into changing the details it was trying to auth using either something like a suitably crafted URL in the form http://invalid:login@www.example.com/ or HTTP header faffery, IIRC). Now, this may all seem a bit bizzare, but there are situations when you are dealing with distributed systems and data that isn't stored in an SQL database and where using a database just for session storage would be far more trouble than it's worth and for technical reasons doesn't fit with the design (e.g. when you just have some admin users looking at some static back end content, and hitting a different distributed host each time they make an HTTP request). Obviously common sense is required when weighing up if this sort of thing is appropriate or just fruity - I'm certainly not advocating that anyone avoid using sessions as a default position for your average website. |
Re: My Kind of Random
2007-06-04 11:43
•
by
Iain Collins
(unregistered)
|
|
...of course I should say we are both primarily refering to ".htpasswd" files when talking about .htaccess in this instance, before some pedant points it out. 8)
|
|
And that, my friends, is why all development environments come with syntax highlighting so that if there is an issue with a missing comment symbol, or quotation, or semicolon, or period etc.. it's pretty obvious since the code in the following line is the wrong colour. If people didn't code in Notepad, they wouldn't spend two days figuring out that a chunk of code was commented out.
|
Re: My Kind of Random
2007-06-04 19:08
•
by
Your Name
(unregistered)
|
|
Some editors (like vi) don't truncate lines, they wrap them, so no matter how much smaller the screen width is than the line you're looking at, you see the whole line.
I feel that's a better method for me than the syntax highlighting stuff, because I'm old and all those colors are a bit confusing. I imagine if I'd grown up with color, it'd be fine. |
Re: My Kind of Random
2007-06-04 21:36
•
by
Old Wolf
(unregistered)
|
DEVELOPMent tEST prodUCTION |
Re: My Kind of Random
2007-06-23 06:43
•
by
Aaron
(unregistered)
|
|
Access logs are indiscriminate in what they record, and sometimes, wide open to google and others
|
Re: My Kind of Random
2009-08-05 08:37
•
by
Craig
(unregistered)
|
I couldn't agree more. Real Programmers(TM) use vi! |
| « Prev | Page 1 | Next » |
Aidan: