Ignore:
Timestamp:
30/12/12 09:19:07 (8 years ago)
Author:
fielding@…
Message:

(editorial) move p1 security considerations regarding semantics to p2

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2069 r2070  
    34953495</t>
    34963496
    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 resources
    3501    (e.g., the user's name, location, mail address, passwords, encryption
    3502    keys, etc.) and information about the user's browsing activity over
    3503    time (e.g., history, bookmarks, etc.). HTTP implementations need to
    3504    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's
    3511    requests which might identify their reading patterns or subjects of
    3512    interest.  In particular, log information gathered at an intermediary
    3513    often contains a history of user agent interaction, across a multitude
    3514    of sites, that can be traced to individual users.
    3515 </t>
    3516 <t>
    3517    HTTP log information is confidential in nature; its handling is often
    3518    constrained by laws and regulations.  Log information needs to be securely
    3519    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 being
    3522    re-identified based on correlation with other access characteristics.
    3523    As such, access traces that are keyed to a specific client should not
    3524    be published even if the key is pseudonymous.
    3525 </t>
    3526 <t>
    3527    To minimize the risk of theft or accidental publication, log information
    3528    should be purged of personally identifiable information, including
    3529    user identifiers, IP addresses, and user-provided query parameters,
    3530    as soon as that information is no longer necessary to support operational
    3531    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 restrict
    3538    the documents sent in response to HTTP requests to be only those that were
    3539    intended by the server administrators. If an HTTP server translates
    3540    HTTP URIs directly into file system calls, the server &MUST; take
    3541    special care not to serve files that were not intended to be
    3542    delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
    3543    other operating systems use ".." as a path component to indicate a
    3544    directory level above the current one. On such a system, an HTTP
    3545    server &MUST; disallow any such construct in the request-target if it
    3546    would otherwise allow access to a resource outside those intended to
    3547    be accessible via the HTTP server. Similarly, files intended for
    3548    reference only internally to the server (such as access control
    3549    files, configuration files, and script code) &MUST; be protected from
    3550    inappropriate retrieval, since they might contain sensitive
    3551    information.
    3552 </t>
    3553 </section>
    3554 
    35553497<section title="DNS-related Attacks" anchor="dns.related.attacks">
    35563498<t>
    … …  
    36453587   user to distinguish between a complete and incomplete response message
    36463588   (<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.
    36473616</t>
    36483617</section>
Note: See TracChangeset for help on using the changeset viewer.