From: Ken Coar Date: Tue, 8 Apr 1997 12:42:36 +0000 (+0000) Subject: Enhance the FAQ with info about "I wanna use /etc/passwd for Web X-Git-Tag: APACHE_1_2b9~75 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=81eba82f7c160a26fadfb2edef4327814c16a1bb;p=apache Enhance the FAQ with info about "I wanna use /etc/passwd for Web authentication", and inadvertent POST restriction by omitting the method from blocks. (Many thanks to Rob H and Marc S for portions of the former.) git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@77817 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/misc/FAQ.html b/docs/manual/misc/FAQ.html index 0c553f7c6c..1dc18d064a 100644 --- a/docs/manual/misc/FAQ.html +++ b/docs/manual/misc/FAQ.html @@ -21,7 +21,6 @@ - @@ -499,6 +504,80 @@ available in the way of solutions.

+
  • + Why do I keep getting "access denied" for form POST + requests? + +

    + The most common cause of this is a <Limit> section + that only names the GET method. Look in your + configuration files for something that resembles the following and + would affect the location where the POST-handling script resides: +

    + 
    +   <Limit GET>
+      :
+
    +

    + Change that to <Limit GET POST> and the problem + will probably go away. +

    +
    +
    • +
  • + Can I use my /etc/passwd file + for Web page authentication? + +

    + Yes, you can - but it's a very bad idea. Here are + some of the reasons: +

    +
      +
    • The Web technology provides no governors on how often or how + rapidly password (authentication failure) retries can be made. That + means that someone can hammer away at your system's + root password using the Web, using a dictionary or + similar mass attack, just as fast as the wire and your server can + handle the requests. Most operating systems these days include + attack detection (such as n failed passwords for the same + account within m seconds) and evasion (breaking the + connexion, disabling the account under attack, disabling + all logins from that source, et cetera), but the + Web does not. +
      • +
    • An account under attack isn't notified (unless the server is + heavily modified); there's no "You have 19483 login + failures" message when the legitimate owner logs in. +
      • +
    • Without an exhaustive and error-prone examination of the server + logs, you can't tell whether an account has been compromised. + Detecting that an attack has occurred, or is in progress, is fairly + obvious, though - if you look at the logs. +
      • +
    • Web authentication passwords (at least for Basic authentication) + generally fly across the wire, and through intermediate proxy + systems, in what amounts to plaintext. "O'er the net we + go/Caching all the way;/O what fun it is to surf/Giving my password + away!" +
      • +
    • Since HTTP is stateless, information about the authentication is + transmitted each and every time a request is made to the + server. Essentially, the client caches it after the first + successful access, and transmits it without asking for all + subsequent requests to the same server. +
      • +
    • It's relatively trivial for someone on your system to put up a + page that will steal the cached password from a client's cache. Can + you say "password grabber"? +
      • +
    +

    + If you still want to do this in light of the above disadvantages, the + method is left as an exercise for the reader. It'll void your Apache + warranty, though, and you'll lose all accumulated UNIX guru points. +

    +
    +