Documentation Source Text

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Changes to pages/security.in.

     1         -<title>Resistance To Attack</title>
     2         -<tcl>hd_keywords security {attack resistance}</tcl>
            1  +<title>Defense Against Dark Arts</title>
            2  +<tcl>hd_keywords security {attack resistance} \
            3  +  {defense against dark arts}</tcl>
     3      4   <fancy_format>
     4      5   
     5      6   <h1>SQLite Always Validates Its Inputs</h1>
     6      7   
     7      8   <p>
     8      9   SQLite should never crash, overflow a buffer, leak memory,
     9     10   or exhibit any other harmful behavior, even with presented with
    10     11   maliciously malformed SQL inputs or database files.  SQLite should
    11         -always detected erroneous inputs and raise an error, not crash or
           12  +always detect erroneous inputs and raise an error, not crash or
    12     13   corrupt memory.
    13     14   Any malfunction caused by an SQL input or database file
    14     15   is considered a serious bug and will be promptly addressed when
    15     16   brought to the attention of the SQLite developers.  SQLite is
    16         -extensively fuzz-tested to help ensure that it is highly resistant
           17  +extensively fuzz-tested to help ensure that it is resistant
    17     18   to these kinds of errors.
    18     19   
    19     20   <p>
    20     21   Nevertheless, bugs happen.
    21     22   If you are writing an application that sends untrusted SQL inputs
    22     23   or database files to SQLite, there are additional steps you can take
    23         -to help prevent zero-day exploits caused by undetected bugs:
           24  +to help reduce the attack surface and
           25  +prevent zero-day exploits caused by undetected bugs.
    24     26   
    25     27   <h2>Untrusted SQL Inputs</h2>
    26     28   <p>
    27     29   Applications that accept untrusted SQL inputs should take the following
    28     30   precautions:
    29     31   
    30     32   <ol>
    31     33   <li><p>
    32     34   Set the [SQLITE_DBCONFIG_DEFENSIVE] flag.
    33         -This prevents ordinary SQL statements from corrupted the database
           35  +This prevents ordinary SQL statements from corrupting the database
    34     36   file.
    35     37   
    36     38   <li><p>
    37     39   Consider using the [sqlite3_set_authorizer()] interface to limit
    38     40   the scope of SQL that will be processed.
    39     41   </ol>
    40     42   
................................................................................
    41     43   <h2>Untrusted SQLite Database Files</h2>
    42     44   
    43     45   <p>Applications that accept untrusted database files should do the following:
    44     46   
    45     47   <ol>
    46     48   <li value="3"><p>
    47     49   Run [PRAGMA integrity_check] or [PRAGMA quick_check] on the database
    48         -first, prior to running any other SQLite, and reject the file if any
    49         -errors are detected.
           50  +as the first SQL statement after opening the database files and
           51  +prior to running any other SQL statements.  Reject and refuse to
           52  +process any database file containing errors.
    50     53   
    51     54   <li><p>
    52     55   Enable the [PRAGMA cell_size_check=ON] setting.
           56  +
           57  +<li><p>
           58  +Do not enable memory-mapped I/O.
           59  +In other words, make sure that [PRAGMA mmap_size=0].
    53     60   </ol>
    54     61   
    55     62   <h1>Summary</h1>
    56     63   
    57     64   <p>
    58     65   The precautions above are not required in order to use SQLite safely
    59     66   with potentially hostile inputs.
    60     67   However, they do provide an extra layer of defense against zero-day
    61     68   exploits and are encouraged for applications that pass data from
    62     69   untrusted sources into SQLite.