Changeset 2070 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 30/12/12 09:19:07 (8 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r2069 r2070 3495 3495 </t> 3496 3496 3497 <section title="Personal Information" anchor="personal.information">3498 <t>3499 HTTP clients are often privy to large amounts of personal information,3500 including both information provided by the user to interact with resources3501 (e.g., the user's name, location, mail address, passwords, encryption3502 keys, etc.) and information about the user's browsing activity over3503 time (e.g., history, bookmarks, etc.). HTTP implementations need to3504 prevent unintentional leakage of this information.3505 </t>3506 </section>3507 3508 <section title="Abuse of Server Log Information" anchor="abuse.of.server.log.information">3509 <t>3510 A server is in the position to save personal data about a user's3511 requests which might identify their reading patterns or subjects of3512 interest. In particular, log information gathered at an intermediary3513 often contains a history of user agent interaction, across a multitude3514 of sites, that can be traced to individual users.3515 </t>3516 <t>3517 HTTP log information is confidential in nature; its handling is often3518 constrained by laws and regulations. Log information needs to be securely3519 stored and appropriate guidelines followed for its analysis.3520 Anonymization of personal information within individual entries helps,3521 but is generally not sufficient to prevent real log traces from being3522 re-identified based on correlation with other access characteristics.3523 As such, access traces that are keyed to a specific client should not3524 be published even if the key is pseudonymous.3525 </t>3526 <t>3527 To minimize the risk of theft or accidental publication, log information3528 should be purged of personally identifiable information, including3529 user identifiers, IP addresses, and user-provided query parameters,3530 as soon as that information is no longer necessary to support operational3531 needs for security, auditing, or fraud control.3532 </t>3533 </section>3534 3535 <section title="Attacks Based On File and Path Names" anchor="attack.pathname">3536 <t>3537 Origin servers &SHOULD; be careful to restrict3538 the documents sent in response to HTTP requests to be only those that were3539 intended by the server administrators. If an HTTP server translates3540 HTTP URIs directly into file system calls, the server &MUST; take3541 special care not to serve files that were not intended to be3542 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and3543 other operating systems use ".." as a path component to indicate a3544 directory level above the current one. On such a system, an HTTP3545 server &MUST; disallow any such construct in the request-target if it3546 would otherwise allow access to a resource outside those intended to3547 be accessible via the HTTP server. Similarly, files intended for3548 reference only internally to the server (such as access control3549 files, configuration files, and script code) &MUST; be protected from3550 inappropriate retrieval, since they might contain sensitive3551 information.3552 </t>3553 </section>3554 3555 3497 <section title="DNS-related Attacks" anchor="dns.related.attacks"> 3556 3498 <t> … … 3645 3587 user to distinguish between a complete and incomplete response message 3646 3588 (<xref target="incomplete.messages"/>) when such verification is desired. 3589 </t> 3590 </section> 3591 3592 <section title="Server Log Information" anchor="abuse.of.server.log.information"> 3593 <t> 3594 A server is in the position to save personal data about a user's requests 3595 over time, which might identify their reading patterns or subjects of 3596 interest. In particular, log information gathered at an intermediary 3597 often contains a history of user agent interaction, across a multitude 3598 of sites, that can be traced to individual users. 3599 </t> 3600 <t> 3601 HTTP log information is confidential in nature; its handling is often 3602 constrained by laws and regulations. Log information needs to be securely 3603 stored and appropriate guidelines followed for its analysis. 3604 Anonymization of personal information within individual entries helps, 3605 but is generally not sufficient to prevent real log traces from being 3606 re-identified based on correlation with other access characteristics. 3607 As such, access traces that are keyed to a specific client should not 3608 be published even if the key is pseudonymous. 3609 </t> 3610 <t> 3611 To minimize the risk of theft or accidental publication, log information 3612 should be purged of personally identifiable information, including 3613 user identifiers, IP addresses, and user-provided query parameters, 3614 as soon as that information is no longer necessary to support operational 3615 needs for security, auditing, or fraud control. 3647 3616 </t> 3648 3617 </section>
Note: See TracChangeset
for help on using the changeset viewer.