Fossil

Check-in [0aa3483fa8]
Login

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

Overview
Comment:Improved comments on the SQL protection subsystem.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 0aa3483fa89b6226fab3aca264cbd85e2f3db67b4d92d4d718f4412fb2c31dc9
User & Date: drh 2022-12-29 20:09:44.850
Context
2022-12-29
21:09
All writes to the subscriber table to update the last contact time even if the request is not from the same origin. check-in: db16262817 user: drh tags: trunk
20:09
Improved comments on the SQL protection subsystem. check-in: 0aa3483fa8 user: drh tags: trunk
19:49
Only apply the PROTECT_READONLY restriction to the "repository", "configdb", and "localdb" database files. check-in: b4e00621e3 user: drh tags: trunk
Changes
Unified Diff Ignore Whitespace Patch
Changes to src/db.c.
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
** -------------------------------
**
** This is *not* a primary means of defending the application from
** attack.  Fossil should be secure even if this mechanism is disabled.
** The purpose of database write protection is to provide an additional
** layer of defense in case SQL injection bugs somehow slip into other
** parts of the system.  In other words, database write protection is
** not primary defense but rather defense in depth.
**
** This mechanism mostly focuses on the USER table, to prevent an
** attacker from giving themselves Admin privilegs, and on the
** CONFIG table and specially "sensitive" settings such as
** "diff-command" or "editor" that if compromised by an attacker
** could lead to an RCE.
**
** By default, the USER and CONFIG tables are read-only.  Various
** subsystems that legitimately need to change those tables can
** temporarily do so using:
**







|



|







367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
** -------------------------------
**
** This is *not* a primary means of defending the application from
** attack.  Fossil should be secure even if this mechanism is disabled.
** The purpose of database write protection is to provide an additional
** layer of defense in case SQL injection bugs somehow slip into other
** parts of the system.  In other words, database write protection is
** not the primary defense but rather defense in depth.
**
** This mechanism mostly focuses on the USER table, to prevent an
** attacker from giving themselves Admin privilegs, and on the
** CONFIG table and especially "sensitive" settings such as
** "diff-command" or "editor" that if compromised by an attacker
** could lead to an RCE.
**
** By default, the USER and CONFIG tables are read-only.  Various
** subsystems that legitimately need to change those tables can
** temporarily do so using:
**
397
398
399
400
401
402
403










404
405
406
407
408
409
410
** pages) are still writable, however.
**
** The PROTECT_SENSITIVE protection is a subset of PROTECT_CONFIG
** that blocks changes to all of the global_config table, but only
** "sensitive" settings in the config table.  PROTECT_SENSITIVE
** relies on triggers and the protected_setting() SQL function to
** prevent changes to sensitive settings.










**
** Additional Notes
** ----------------
**
** Calls to routines like db_set() and db_unset() temporarily disable
** the PROTECT_CONFIG protection.  The assumption is that these calls
** cannot be invoked by an SQL injection and are thus safe.  Make sure







>
>
>
>
>
>
>
>
>
>







397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
** pages) are still writable, however.
**
** The PROTECT_SENSITIVE protection is a subset of PROTECT_CONFIG
** that blocks changes to all of the global_config table, but only
** "sensitive" settings in the config table.  PROTECT_SENSITIVE
** relies on triggers and the protected_setting() SQL function to
** prevent changes to sensitive settings.
**
** PROTECT_READONLY is set for any HTTP request for which the HTTP_REFERER
** is not the same origin.  This is an additional defense against cross-site-
** scripting attacks.  As with all of these defenses, this is only an extra
** backup layer.  Fossil should be proof against XSS attacks even without this.
**
** Any violation of these security restrictions results in a SECURITY message
** in the server log (if enabled).  A violation of any of these restrictions
** probably indicates a bug in Fossil and should be reported to the
** developers.
**
** Additional Notes
** ----------------
**
** Calls to routines like db_set() and db_unset() temporarily disable
** the PROTECT_CONFIG protection.  The assumption is that these calls
** cannot be invoked by an SQL injection and are thus safe.  Make sure