Fossil SCM
Improved comments on the SQL protection subsystem.
Commit
0aa3483fa89b6226fab3aca264cbd85e2f3db67b4d92d4d718f4412fb2c31dc9
Parent
b4e00621e3fb6b3…
1 file changed
+12
-2
M
src/db.c
+12
-2
| --- src/db.c | ||
| +++ src/db.c | ||
| @@ -369,15 +369,15 @@ | ||
| 369 | 369 | ** This is *not* a primary means of defending the application from |
| 370 | 370 | ** attack. Fossil should be secure even if this mechanism is disabled. |
| 371 | 371 | ** The purpose of database write protection is to provide an additional |
| 372 | 372 | ** layer of defense in case SQL injection bugs somehow slip into other |
| 373 | 373 | ** parts of the system. In other words, database write protection is |
| 374 | -** not primary defense but rather defense in depth. | |
| 374 | +** not the primary defense but rather defense in depth. | |
| 375 | 375 | ** |
| 376 | 376 | ** This mechanism mostly focuses on the USER table, to prevent an |
| 377 | 377 | ** attacker from giving themselves Admin privilegs, and on the |
| 378 | -** CONFIG table and specially "sensitive" settings such as | |
| 378 | +** CONFIG table and especially "sensitive" settings such as | |
| 379 | 379 | ** "diff-command" or "editor" that if compromised by an attacker |
| 380 | 380 | ** could lead to an RCE. |
| 381 | 381 | ** |
| 382 | 382 | ** By default, the USER and CONFIG tables are read-only. Various |
| 383 | 383 | ** subsystems that legitimately need to change those tables can |
| @@ -399,10 +399,20 @@ | ||
| 399 | 399 | ** The PROTECT_SENSITIVE protection is a subset of PROTECT_CONFIG |
| 400 | 400 | ** that blocks changes to all of the global_config table, but only |
| 401 | 401 | ** "sensitive" settings in the config table. PROTECT_SENSITIVE |
| 402 | 402 | ** relies on triggers and the protected_setting() SQL function to |
| 403 | 403 | ** prevent changes to sensitive settings. |
| 404 | +** | |
| 405 | +** PROTECT_READONLY is set for any HTTP request for which the HTTP_REFERER | |
| 406 | +** is not the same origin. This is an additional defense against cross-site- | |
| 407 | +** scripting attacks. As with all of these defenses, this is only an extra | |
| 408 | +** backup layer. Fossil should be proof against XSS attacks even without this. | |
| 409 | +** | |
| 410 | +** Any violation of these security restrictions results in a SECURITY message | |
| 411 | +** in the server log (if enabled). A violation of any of these restrictions | |
| 412 | +** probably indicates a bug in Fossil and should be reported to the | |
| 413 | +** developers. | |
| 404 | 414 | ** |
| 405 | 415 | ** Additional Notes |
| 406 | 416 | ** ---------------- |
| 407 | 417 | ** |
| 408 | 418 | ** Calls to routines like db_set() and db_unset() temporarily disable |
| 409 | 419 |
| --- src/db.c | |
| +++ src/db.c | |
| @@ -369,15 +369,15 @@ | |
| 369 | ** This is *not* a primary means of defending the application from |
| 370 | ** attack. Fossil should be secure even if this mechanism is disabled. |
| 371 | ** The purpose of database write protection is to provide an additional |
| 372 | ** layer of defense in case SQL injection bugs somehow slip into other |
| 373 | ** parts of the system. In other words, database write protection is |
| 374 | ** not primary defense but rather defense in depth. |
| 375 | ** |
| 376 | ** This mechanism mostly focuses on the USER table, to prevent an |
| 377 | ** attacker from giving themselves Admin privilegs, and on the |
| 378 | ** CONFIG table and specially "sensitive" settings such as |
| 379 | ** "diff-command" or "editor" that if compromised by an attacker |
| 380 | ** could lead to an RCE. |
| 381 | ** |
| 382 | ** By default, the USER and CONFIG tables are read-only. Various |
| 383 | ** subsystems that legitimately need to change those tables can |
| @@ -399,10 +399,20 @@ | |
| 399 | ** The PROTECT_SENSITIVE protection is a subset of PROTECT_CONFIG |
| 400 | ** that blocks changes to all of the global_config table, but only |
| 401 | ** "sensitive" settings in the config table. PROTECT_SENSITIVE |
| 402 | ** relies on triggers and the protected_setting() SQL function to |
| 403 | ** prevent changes to sensitive settings. |
| 404 | ** |
| 405 | ** Additional Notes |
| 406 | ** ---------------- |
| 407 | ** |
| 408 | ** Calls to routines like db_set() and db_unset() temporarily disable |
| 409 |
| --- src/db.c | |
| +++ src/db.c | |
| @@ -369,15 +369,15 @@ | |
| 369 | ** This is *not* a primary means of defending the application from |
| 370 | ** attack. Fossil should be secure even if this mechanism is disabled. |
| 371 | ** The purpose of database write protection is to provide an additional |
| 372 | ** layer of defense in case SQL injection bugs somehow slip into other |
| 373 | ** parts of the system. In other words, database write protection is |
| 374 | ** not the primary defense but rather defense in depth. |
| 375 | ** |
| 376 | ** This mechanism mostly focuses on the USER table, to prevent an |
| 377 | ** attacker from giving themselves Admin privilegs, and on the |
| 378 | ** CONFIG table and especially "sensitive" settings such as |
| 379 | ** "diff-command" or "editor" that if compromised by an attacker |
| 380 | ** could lead to an RCE. |
| 381 | ** |
| 382 | ** By default, the USER and CONFIG tables are read-only. Various |
| 383 | ** subsystems that legitimately need to change those tables can |
| @@ -399,10 +399,20 @@ | |
| 399 | ** The PROTECT_SENSITIVE protection is a subset of PROTECT_CONFIG |
| 400 | ** that blocks changes to all of the global_config table, but only |
| 401 | ** "sensitive" settings in the config table. PROTECT_SENSITIVE |
| 402 | ** relies on triggers and the protected_setting() SQL function to |
| 403 | ** prevent changes to sensitive settings. |
| 404 | ** |
| 405 | ** PROTECT_READONLY is set for any HTTP request for which the HTTP_REFERER |
| 406 | ** is not the same origin. This is an additional defense against cross-site- |
| 407 | ** scripting attacks. As with all of these defenses, this is only an extra |
| 408 | ** backup layer. Fossil should be proof against XSS attacks even without this. |
| 409 | ** |
| 410 | ** Any violation of these security restrictions results in a SECURITY message |
| 411 | ** in the server log (if enabled). A violation of any of these restrictions |
| 412 | ** probably indicates a bug in Fossil and should be reported to the |
| 413 | ** developers. |
| 414 | ** |
| 415 | ** Additional Notes |
| 416 | ** ---------------- |
| 417 | ** |
| 418 | ** Calls to routines like db_set() and db_unset() temporarily disable |
| 419 |