The Joomla! Forum ™

Thanks everybody for the suggested file.

One more idea from a newbe: There is a lot of suggestions on the web to disable HTTP TRACE and TRACK methods (e.g. http://publib.boulder.ibm.com/httpserv/ ... trace.html or just google for "http trace track"), to prevent cross-side tracing attacks. Would that be something to also be added to the file?

Maybe together with HEAD and DELETE methods, as in "Other useful settings" on http://docs.joomla.org/Htaccess_examples_%28security%29 ?

Cheers!

Yes, certainly worth considering. Thanks! The suggestions I fed back to the original author several months ago haven't been acknowledged or actioned. At some point, when I have a bit more time, I might fork the entire project and make a whole load more changes that I have noted over the last few months.

_________________
Online since 1995.

Trace is not a vulnerability in the TRACE command, or in the Apache web server. Rather it is a browser issue that can occur with certain browsers that can be scripted. The TRACE request has been blown out of proportion by the press who do not understand what they are reporting on.
This was first reported in 2003 I believe, and would probably be better served if turned off on the server and it may have been fixed within the browser in question.

I don't think most people need to be concerned greatly about the issue (personal opinion only), though it is possible a hacked site could be serving the carefully crafted pages to gain online banking credentials I suppose. I'm not saying it should be or should not be added. It probably should, though if an attacker has access to your site to insert the pages etc., they can remove it from htaccess.

For those who don't understand much about this issue, read on. The info below came from the sites I referenced below which do a better job of explaining the issue than the site posted in the above post.

When an HTTP TRACE request is sent to a web server the server will respond by echoing the data that is passed to it, including any HTTP headers. As the paper explains, some browsers can be scripted to perform a TRACE request. A browser with this functionality can be made to issue a TRACE request against an arbitrary site and pass the results on to a different place. Browsers will only send authentication details and cookies to the sites that issue them. This means a user having a browser with scripting functionality could be tricked into sending cookies or authentication details for arbitrary sites to an attacker.

For example, if you visited a site that has a page that an attacker has carefully crafted, the page could cause your browser to bounce a TRACE request against some other site for which you have authentication cookies for. The result of the TRACE will be a copy of what was sent to the site bounced against. This will include cookies and/or other authentication data from that site bounced against. The carefully crafted page from the site that was attacked can then pass that information on to the attacker.

The same browser functionality that permits the published TRACE attack can be used for different attacks even if TRACE is disabled on the remote web server. For example an attacker could again create a carefully crafted page that when visited submits a hidden request to some arbitrary site through your browser, grabs the result and passes it to the attacker.

Reference:
In the news, Cross-Site Tracing issues
http://www.apacheweek.com/issues/03-01-24#news

WhitePaper, TRACE Request Method
http://www.cgisecurity.com/whitehat-mir ... _ebook.pdf

_________________
PhilD -- Unrequested PM's and/or emails may not get a response.
Security Moderator

leolam,

I realize this post in months old. However, I just joined this forum and found it. Thanks for the info, and the link to the htaccess file. Been looking for something like this for a *while*.

_________________
http://www.livingsimply.org.

Thanks for the clarifications on TRACE. It is not an issue that I am all that familiar with. I've tossed it into the list of "stuff to think about" that I have been slowly compiling over the last few months.

_________________
Online since 1995.

Hi. I started using the htaccess file by Nicholas Dionysopoulos, and I'm having some trouble with a few components (specifically the K2 frontend editor, Phocagallery, and jwplayer in RokBox). Getting "The requested document was not found on this server" in a lightbox-like popup.

I'm guessing I need to write rules to allow access to those, or alter whatever rules are blocking them.
Please help! And let me know if this should be posted elsewhere.

please direct your comments and questions to the author of that document.
the htaccess file bring discussed within these pages are a "fork" version of that file that no longer bear any relationshp to the original

_________________
HU2HY- Poor questions = Poor answer
Un requested Help PM's will be added to the foe list and possibly just deleted
{Community.Connect Administrator }{ Showcase & Security Moderator}

@C0nw0nk
I have deleted your post and again locked the thread against further posts as I have asked everyone time and again not to post additional code they want to see included to this particular topic thread.

The existing code block is being actively worked upon, to make it efficient, to work as designed, and to be well commented in each section. To constantly add additional code from outside sources will only serve to pollute the existing code base that is currently being worked upon.

g1smd, mandville, and myself appreciate everyone's understanding in this matter.

If you have found errors within the existing suggested master htaccess file, then please for the moment PM me the problem description, and the code block or line(s) that you think may be causing the issues.

_________________
PhilD -- Unrequested PM's and/or emails may not get a response.
Security Moderator