-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1796503:1933855 (outdated) -->
+<!-- English Revision: 1933855 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<ul>
<li>
- <a href="http://purl.org/NET/http-errata">
- http://purl.org/NET/http-errata</a> - Corrections de la
+ <a href="https://www.skrb.org/ietf/http_errata.html">
+ https://www.skrb.org/ietf/http_errata.html</a> - Corrections de la
spécification HTTP/1.1
</li>
<li>
- <a href="http://www.rfc-editor.org/errata.php">
- http://www.rfc-editor.org/errata.php</a> - Corrections des RFCs
+ <a href="https://www.rfc-editor.org/errata.php">
+ https://www.rfc-editor.org/errata.php</a> - Corrections des RFCs
</li>
<li>
- <a href="http://ftp.ics.uci.edu/pub/ietf/http/#RFC">
- http://ftp.ics.uci.edu/pub/ietf/http/#RFC</a> - Une liste
+ <a href="https://httpwg.org/specs/">
+ https://httpwg.org/specs/</a> - Une liste
précompilée des RFCs en rapport avec HTTP
</li>
</ul>
<section id="http_recommendations"><title>Recommandations HTTP</title>
- <p>Indépendamment des modules compilés et utilisés, Apache en
+ <p>Sans tenir compte des modules compilés et utilisés, Apache en
tant que serveur web de base respecte les recommandations IETF
suivantes :</p>
<dl>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc1945.txt">RFC 1945</a>
+ <dt><rfc>1945</rfc>
(Informations)</dt>
<dd>Le Protocole de Transfert Hypertexte (Hypertext Transfer
distribués, collaboratifs et hypermédia. Cette RFC documente le
protocole HTTP/1.0.</dd>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc2616.txt">RFC 2616</a>
+ <dt><rfc>2616</rfc>
(Série de standards)</dt>
<dd>Le Protocole de Transfert Hypertexte (Hypertext Transfer
systèmes d'informations distribués, collaboratifs et hypermédia.
Cette RFC documente le protocole HTTP/1.1.</dd>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc2396.txt">RFC 2396</a>
+ <dt><rfc>2396</rfc>
(Série de standards)</dt>
<dd>Un Identificateur de Ressource Uniforme (Uniform Resource
Identifier - URI) est une chaîne de caractères compacte permettant
d'identifier une ressource physique ou abstraite.</dd>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc4346.txt">RFC 4346</a>
+ <dt><rfc>4346</rfc>
(Série de standards)</dt>
<dd>Le protocole TLS permet l'utilisation de communications
recommandations IETF et W3C suivantes :</p>
<dl>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc2854.txt">RFC 2854</a>
+ <dt><rfc>2854</rfc>
(Informations)</dt>
<dd>Ce document résume l'historique du développement de HTML, et
4.01</a>
(<a
href="http://www.w3.org/MarkUp/html4-updates/errata">Corrections
- d'erreurs</a>)
+ Erreurs</a>)
</dt>
<dd>Cette spécification définit le Langage à Balises HyperTexte
Apache respecte les recommandations IETF suivantes :</p>
<dl>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc2617.txt">RFC 2617</a>
- (Le track des standards)</dt>
+ <dt><rfc>2617</rfc>
+ (Série de standards)</dt>
- <dd>"HTTP/1.0", y compris la spécification d'un protocole basique
- d'authentification et de contrôle d'accès.</dd>
+ <dd>"HTTP/1.0", y compris la spécification d'un protocole
+ d'authentification et de contrôle d'accès basique.</dd>
</dl>
</section>
- <section id="language_country_codes"><title>Codes de langues et de
+ <section id="language_country_codes"><title>Codes de langages et de
pays</title>
<p>Les liens suivants fournissent des informations à propos des
- codes de langues et de pays aux normes ISO ou autres :</p>
+ codes de langages et de pays aux normes ISO ou autres :</p>
<dl>
<dt><a href="http://www.loc.gov/standards/iso639-2/">ISO 639-2</a></dt>
- <dd>ISO 639 fournit deux jeux de codes de langues permettant de
+ <dd>ISO 639 fournit deux jeux de codes de langages permettant de
représenter les noms des langues ; le premier est
un jeu de codes sur deux lettres (639-1), le second (celui
présenté dans le lien ci-dessus), est un jeu de codes sur trois
présentés dans la norme ISO 3166-1 et les éléments de codes
correspondants de la norme ISO 3166-1-alpha-2.</dd>
- <dt><a href="http://www.rfc-editor.org/rfc/bcp/bcp47.txt">BCP 47</a>
- (Les meilleurs pratiques courantes),
- <a href="http://www.rfc-editor.org/rfc/rfc3066.txt">RFC 3066</a></dt>
+ <dt><a href="https://www.rfc-editor.org/rfc/bcp/bcp47.txt">BCP 47</a> (Les
+ meilleurs pratiques courantes), <rfc>3066</rfc></dt>
<dd>Ce document décrit une balise de langue permettant de
- spécifier la langue utilisé dans un objet contenant des
+ spécifier la langue utilisée dans un objet contenant des
informations, la manière d'enregistrer des valeurs à utiliser dans
- cette balise de langage, et une méthode pour comparer les balises
+ cette balise de langue, et une méthode pour comparer les balises
de langue de ce style.</dd>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc3282.txt">RFC 3282</a>
+ <dt><rfc>3282</rfc>
(Série de standards)</dt>
- <dd>Ce document définit un en-tête "Content-language:" permettant
- de spécifier le langage d'un élément possédant des en-têtes du
+ <dd>Ce document définit une en-tête "Content-language:" permettant
+ de spécifier la langue d'un élément possédant des en-têtes du
style RFC 822, comme les portions de corps MIME ou les documents
Web, et un en-tête "Accept-Language:" permettant de spécifier des
préférences en matière de langue.</dd>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1918790:1933419 (outdated) -->
+<!-- English Revision: 1933419 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
</section>
+ <section id="dynamicsec">
+
+ <title>Sécurité des contenus dynamiques</title>
+
+ <p>Quand vous utilisez des cadriciels à contenu dynamique — que ce soit à
+ travers <code>mod_php</code>, <code>mod_perl</code>, <code>mod_python</code>
+ ou tout autre générateur de contenu intégré ou externe — les responsabilités
+ en matière de sécurité s’étendent au-delà de httpd lui-même. Chaque cadriciel
+ possède ses propres modèle de sécurité, options de configuration et guides de
+ durcissement. Consultez la documentation de la technologie que vous utilisez
+ pour générer du contenu dynamique et maintenez cette dernière à jour.</p>
+
+ <p>Les principes généraux s’appliquent à tout cadriciel :</p>
+ <ul>
+ <li>Accordez des privilèges minimaux à vos scripts et applications.</li>
+ <li>Vérifiez et nettoyez toute entrée de l’utilisateur.</li>
+ <li>Maintenez à jour votre cadriciel de contenu et ses dépendances.</li>
+ <li>Vérifiez la configuration de la sécurité de votre cadriciel — les valeurs
+ par défaut ne sont pas toujours appropriées en matière de sécurité.</li>
+ </ul>
+
+ <p>Au niveau de httpd, un pare-feu d’application web tel que <a
+ href="https://modsecurity.org/">ModSecurity</a> peut fournir une couche
+ supplémentaire de défense en inspectant et filtrant le trafic HTTP avant qu’il
+ n’atteigne votre application.</p>
+
+ </section>
+
<section id="systemsettings">
<title>Protection de la configuration du système</title>
<p>Portez une attention particulière aux interactions entre les directives
<directive module="core">Location</directive> et
<directive module="core">Directory</directive> ; par exemple, si une
- directive <code><Directory ""/></code> interdit un accès, une
+ directive <code><Directory "/"></code> interdit un accès, une
directive <code><Location "/"></code> pourra passer outre.</p>
<p>De même, soyez méfiant en jouant avec la directive
<title>Surveillez vos journaux</title>
- <p>Pour vous tenir informé de ce qui se passe réellement dans votre
- serveur, vous devez consulter vos
- <a href="../logs.html">fichiers journaux</a>. Même si les fichiers journaux
- ne consignent que des évènements qui se sont déjà produits, ils vous
- informeront sur la nature des attaques qui sont lancées contre le serveur
- et vous permettront de vérifier si le niveau de sécurité nécessaire est
- atteint.</p>
+ <p>Pour vous tenir informé de ce qui se passe réellement dans votre serveur,
+ consultez régulièrement vos <a href="../logs.html">fichiers journaux</a>.
+ Les fichiers journaux ne consignent que des évènements qui se sont déjà
+ produits, mais ils vous informeront sur la nature des attaques qui sont
+ lancées et vous permettront de vérifier si la configuration de votre
+ sécurité est efficace.</p>
<p>Quelques exemples :</p>
- <example>
- grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br />
- grep "client denied" error_log | tail -n 10
- </example>
-
- <p>Le premier exemple listera les attaques essayant d'exploiter la
- <a href="http://online.securityfocus.com/bid/4876/info/">vulnérabilité
- d'Apache Tomcat pouvant provoquer la divulgation d'informations par des
- requêtes Source.JSP mal formées</a>, le second donnera la liste des dix
- dernières interdictions client ; par exemple :</p>
-
- <example>
- [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
- by server configuration: /usr/local/apache/htdocs/.htpasswd
- </example>
-
- <p>Comme vous le voyez, les fichiers journaux ne consignent que ce qui
- s'est déjà produit ; ainsi, si le client a pu accéder au fichier
- <code>.htpasswd</code>, vous devriez avoir quelque chose du style :</p>
+ <highlight language="sh">
+grep -c "\.\.\/" access_log
+grep "client denied" error_log | tail -n 10
+ </highlight>
+ <p>Le premier exemple compte les requêtes qui contiennent des séquences de
+ traversée de chemin — un signe connu de recherche de vulnérabilités. Le
+ second liste les dix « client denied » les plus récents ; par exemple :</p>
<example>
- foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
+ [Mon Apr 14 09:42:03.817295 2026] [authz_core:error] [pid 1234:tid 5678]
+ [client 192.168.1.100:54312] AH01630: client denied by server configuration:
+ /usr/local/apache2/htdocs/.env
</example>
- <p>dans votre <a href="../logs.html#accesslog">journal des accès</a> ; ce
- qui signifie que vous avez probablement mis en commentaire ce qui suit dans
- le fichier de configuration de votre serveur :</p>
+ <p>Comme vous pouvez le voir, les fichiers journaux ne mentionnent que ce
+ qu’il s’est déjà produit. Si le client avait pu accéder au fichier
+ <code>.env</code>, vous auriez vu une réponse <code>200</code> dans votre
+ fichier <a href="../logs.html#accesslog">Access Log</a> — ce qui aurait
+ signifié que la configuration de votre serveur devait être plus restrictive.
+ Assurez-vous d’interdire l’accès aux fichiers sensibles :</p>
<highlight language="config">
-<Files ".ht*">
+<FilesMatch "^\.(?!well-known)">
Require all denied
-</Files>
+</FilesMatch>
</highlight>
</section>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1933137:1933948 (outdated) -->
+<!-- English Revision: 1933948 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<dt><code><var>realm</var></code></dt>
<dd>Le nom du domaine de protection auquel le nom d'utilisateur
- appartient. Voir <a
- href="http://tools.ietf.org/html/rfc2617#section-3.2.1">http://tools.ietf.org/html/rfc2617#section-3.2.1</a>
+ appartient. Voir la <rfc section="3.2.1">2617</rfc>
pour plus de détails.</dd>
<dt><code><var>nom-utilisateur</var></code></dt>
conséquence, évitez de lui attribuer des permissions setuid.</p>
</section>
+<section id="files"><title>Fichiers</title>
+
+<p>Le chemin du fichier d’authentification à base de condensés est spécifié en
+tant qu’argument de la ligne de commande et il peut être placé n’importe où dans
+le système de fichiers.</p>
+
+<dl>
+<dt><var>fichier des mots de passe</var></dt>
+<dd>Le fichier plat contenant les noms des utilisateurs, les domaines de
+protection (realms) et les mots de passe hachés.</dd>
+</dl>
+
+</section>
+
</manualpage>
projects / thirdparty / apache / httpd.git / commitdiff
