icydash

Thanks a lot for your comments. I think we had a really great discussion here of a lot of interesting issues. I hope future developers find this thread useful, and I thank everyone for their comments.

gizmola, I think you misunderstood what I was saying. For my particular situation, in which I have some content I'd like to protect but allow a small number of friends (like, less then 10) to access, HTTP Auth seems to be the best method. If instead, for my login script, I used MySQL databases or sessions/cookies to authenticate my users on my site instead of HTTP Auth, my site would be a lot more vulnerable under these particular conditions. If I happen to inadvertently write poor PHP code, it's not particularly difficult for a remote attacker to use MySQL injection or XSS/other attacks to grab login/session/cookie data from the server or an unsuspecting victim. Conversely, the only real way to get HTTP Auth information is to get the headers, which Javascript doesn't have access to. Thus, the only real way to get the HTTP Auth info is really to get between the server and the client somehow. And while your "sitting in a cafe" scenario may work for a HUGE site like Facebook, which millions of people visit daily, I HIGHLY doubt there will be many people sitting in a cafe, where an attacker just happens to be, going to my members area and logging in through which that attacker could steal the credentials. Given the limited number of members, it seems highly improbable an attacker would find a way to get between the server and the client to grab the HTTP Auth headers/credentials. As to your brute force comment, there are now a lot of scripts to prevent brute forcing of HTTP Auth, especially if you're using HTTP Auth through PHP.

I only have a few users that I allow into my "members" area, and while I keep hearing that HTTP Auth is very poor security-wise because it sends the auth info in simply base64 encrypted form, it seems that it's actually one of the better methods of security for protecting limited content. Things like Cookies and Sessions appear much more subject to attack, especially with XSS, and nobody seems to be able to find a way to grab the HTTP Auth info short of somehow getting in-between the server and client, which is a huge feat.

ChristianF: thanks for your response. Indeed, I had missed your earlier post. I see the implications in being able to craft javascript so that the attacker could effectively make the victims browser do what he wants, like drop all the tables in a SQL database. However, the reason I'm not focused on this is because I don't use a MySQL database or cookies for security. The way I protect my content is a folder with HTTP Auth. I give users that I want to be able to access my private data the username and password. So while I see the implications of what you're saying, being able to "control" the victims browser isn't as much of a concern for me; I'm more concerned about the accessibility/security of the private information stored in my "members" folder.

Thanks for your explanation -- I didn't realize the servers response didn't also carry the header information. It makes sense that it didn't work, then. I suppose the only real information you'd be able to steal, like you mentioned, is cookie information stored in document.cookie, which isn't a real problem for me because my site doesn't use cookies; rather, it uses HTTP Auth. What if the server had the HTTP request TRACE activated (like POST, GET)? Doesn't that basically return/echo whatever you send to it? Could I then do an XMLHttpRequest() somehow and have the server bounce back the header information? I think I've read about an attack like that before. Also, how do I even figure out if I have TRACE enabled, haha? Also, would it work if I create malicious code that opens an XMLHttpRequest() to a different server, one that I control, and have the server (using PHP) read the headers and grab the HTTP Auth info (this seems like it'd be a big security oversight if it did allow me to do this)? Or does the browser only send the HTTP Auth header information to the original server, and not to others?

I'm wondering if there's a way to do something like this: <Script language=javascript> var req = new XMLHttpRequest(); req.open('GET', document.location, false); req.send(null); var headers = req.getAllResponseHeaders().toLowerCase(); alert(headers); </script> ...where it grabs the HTTP Authentication header, but I can't seem to get it to work. The above code seems to have all the headers EXCEPT HTTP Auth. If I can get that to work, then instead of an alert, I could have it send the headers to a log.php file on another server and my site would be exploited.

Thanks a lot for your explanation; everything makes a lot more sense now. As to HTTP Authentication, if every time a request is sent, the HTTP Header field name "authorization" has the login credentials, is there a way to maliciously run javascript code to swipe the credentials from the HTTP header of a victim visiting the page? i.e. is there any way to swipe the credentials, if I can get full javascript access using the exploit? I guess I'm trying to determine if this kind of an attack would be more of a nuisance attack (i.e. the attacker can use javascript to make 1000 popups which are annoying, or redirect the user to his/her own website) or if the attack can actually steal sensitive authentication information (i.e. some important cookie information that I don't know exists, or HTTP Authentication information). Thanks again.

What is a DOM? What about areas on my website covered by .htpasswd instead of a form login? I'm not sure how .htpasswd works -- does it leave a cookie on your computer or something? If so, I guess someone could log in to the secure areas and then go to the forum that has the malicious code, and the malicious code could grab the cookie and send it to a website that logs the information. Does anyone know how .htpasswd works? Cookies? Sessions?

Oh... really? Well I guess I'm accidentally pretty safe then, haha. As to JavaScript, other than being annoying (e.g. inserting code that has like 10000 alerts), could anyone actually do anything dangerous to compromise the security of the site / my server?

Hey all, I'm in the middle of coding a forum for fun and a question popped up. I created the usual textarea so that users can input the content they want to post on the forum, and it saves whatever they input to a MySQL table. I was then trying to see if I could break it (to make it more secure), and tried to input as my post "<?php echo $REMOTE_ADDR; ?>" just to see what would happen. It indeed saved "<?php echo $REMOTE_ADDR; ?>" to the MySQL table in the right spot; however, unexpectedly, when I viewed the post, instead of the forum actually running the <?php echo $REMOTE_ADDR; ?> command and displaying my IP like I expected, it literally just output "<?php echo $REMOTE_ADDR; ?>". So I guess my question is: what happened? Why isn't it running the php code like I thought it would? Is there a way to get it to run the PHP code that I'm not thinking of?

Hey guys. So I'm trying to write a script that replaces footnote citations in one format with footnote citations in another format. For example, the text will read: "Then he went down the street.[1] That is where the police found him [2]. They immediately arrested him at the house. [3]" And I would like the script to find the [ #] strings and replace them with {#} ... so that the string reads: "Then he went down the street.{1} That is where the police found him {2}. They immediately arrested him at the house. {3}" Note that there will be double, and even tripple, digit footnotes, so the script has to be able to recognize [##] or [###] and replace the brackets with {} accordingly. I'm not really sure how to do this, since the "pattern" is constantly changing depending on the number between the brackets. Ideas? Thanks!