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