Description (CNA)
FrontAccounting through 2.4.20 generates a CSRF token in end_form() in includes/ui/ui_controls.inc and embeds it as the _token hidden field in every form it renders, but only admin/users.php and admin/change_current_user_password.php call check_csrf_token() to validate it. No financial transaction handler validates the token, including gl/gl_journal.php, gl/gl_bank.php, purchasing/supplier_invoice.php, sales/customer_invoice.php, sales/customer_payments.php and admin/company_preferences.php, so those endpoints act on POST data with no origin check. An attacker who gets an authenticated user to load a page under attacker control can auto-submit a cross-origin form to any of them and have the forged journal entry, invoice, customer payment, bank transaction or company configuration change recorded under the victim's session.
Affected (CNA)
| Vendor / product | Versions |
|---|---|
| FrontAccounting / FrontAccounting | affected 0 through 2.4.20 |
CWE
CWE-352
References
- https://github.com/geo-chen/oss/blob/main/FA.md#finding-1-cross-site-request-forgery-on-financial-transaction-forms-in-frontaccounting
- https://github.com/FrontAccountingERP/FA
- https://github.com/FrontAccountingERP/FA/blob/9464a3ffef03c139d9396e697bce9a0a9f131a72/includes/ui/ui_controls.inc#L89
- https://www.vulncheck.com/advisories/frontaccounting-through-2.4.20-cross-site-request-forgery-on-financial-transaction-forms
ADP enrichment
No English description supplied.
No references supplied.