Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Mention new defensive capabilities in the security.html page. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
b714ca6b9660972bed5e9ce1b008ff2b |
| User & Date: | drh 2019-08-15 23:05:13 |
Context
|
2019-08-29
| ||
| 17:19 | Add a description of NULLS FIRST and NULLS LAST. Add a note about the addition of sqlite3_drop_modules(). (check-in: a7856e4125 user: drh tags: trunk) | |
|
2019-08-15
| ||
| 23:05 | Mention new defensive capabilities in the security.html page. (check-in: b714ca6b96 user: drh tags: trunk) | |
| 22:48 | Update the change log with the latest enhancements. (check-in: b3e162d6ec user: drh tags: trunk) | |
Changes
Changes to pages/security.in.
114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 |
Do not enable memory-mapped I/O. In other words, make sure that [PRAGMA mmap_size=0]. <li><p> A maliciously crafted database might be able to inject SQL by defining new [CREATE TRIGGER|triggers] or [CREATE VIEW|views] in the schema that the application does not anticipate. Therefore, applications that read untrusted databases might want to scan the [sqlite_master] table to look for unexpected triggers and/or views and might also want to deploy the SQL defense techniques described in the previous section. </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. |
| > > > > > > > > > > > | < < > > > > > > > > > > > |
114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 |
Do not enable memory-mapped I/O. In other words, make sure that [PRAGMA mmap_size=0]. <li><p> A maliciously crafted database might be able to inject SQL by defining new [CREATE TRIGGER|triggers] or [CREATE VIEW|views] in the schema that the application does not anticipate. There are multiple defenses: <ol type="a"> <li><p> If the application does not use triggers or views, then disable the unused capabilities using: <blockquote><pre> [sqlite3_db_config](db,[SQLITE_DBCONFIG_ENABLE_TRIGGER],0,0); [sqlite3_db_config](db,[SQLITE_DBCONFIG_ENABLE_VIEW],0,0); </pre></blockquote> </p> <li><p> If the application does use triggers or views, then use queries to scan the [sqlite_master] table to verify that the triggers and views found there are expected, that there are no surplus triggers or views, existing triggers and views have not been tampered with, and that no existing ordinary tables have been replaced by malicious views. </p> </ol> </ol> <p>Even if the application does not deliberately accept database files from untrusted sources, beware of attacks in which a local database file is surreptitiously altered to contain harmful content. <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. |