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: |
0aa3483fa89b6226fab3aca264cbd85e |
| 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
Changes to src/db.c.
| ︙ | ︙ | |||
367 368 369 370 371 372 373 | ** ------------------------------- ** ** 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 | | | | 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 |
| ︙ | ︙ |