Documentation Source Text

Check-in [b714ca6b96]
Login

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
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: b714ca6b9660972bed5e9ce1b008ff2bca245bec1b98e9436c04f376328a8a14
User & Date: drh 2019-08-15 23:05:13.920
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
Unified Diff Ignore Whitespace Patch
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

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








>
>
>
|
>
>
>
>
>
>
>
>
|
<
>
>
>
|
>

>

>
>
>
>
>








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

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
︙︙