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.
Timelines: family | ancestors | trunk
Files: files | file ages | folders
SHA3-256: b714ca6b9660972bed5e9ce1b008ff2bca245bec1b98e9436c04f376328a8a14
User & Date: drh 2019-08-15 23:05:13
Context
2019-08-15
23:05
Mention new defensive capabilities in the security.html page. Leaf 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
Hide Diffs Unified Diffs 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
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.