How White-Box hacking works: InvoicePlane – A Lot Of XSS And A Couple Of BAC Vulnerabilities

Hi all! InvoicePlane is a self-hosted open source application for managing your quotes, invoices, clients and payments. Looks pretty good, especially for hacking laboratories as we are. After a brief review, we found the following issues:

A pile of stored XSS. This Cross-Site Scripting is naturally everywhere. Javascript is being executed in different places of the application:
    In field “Invoice #” of invoice, appearing:
        http://{domain}/index.php/invoices/view/{invoice_id}
        http://{domain}/index.php/dashboard
        http://{domain}/index.php/invoices/status/all
        http://{domain}/index.php/clients/view/{client_id}
        http://{domain}/index.php/guest
        http://{domain}/index.php/guest/invoices/status/open
        In guest URL, e.g.: http://{domain}/index.php/guest/view/invoice/Nmdzjv5fVJb3IHYhL8eTM6RaWX1s7gKc
    In fields “VAT ID” and “Taxes Code” of client, appearing:
        In guest URL, e.g.: http://{domain}/index.php/guest/view/invoice/Nmdzjv5fVJb3IHYhL8eTM6RaWX1s7gKc
    In fields “Client Name” and “Client Surname” of client, appearing:
        http://{domain}/index.php/guest/invoices/view/{invoice_id}

Image 1. Changing Invoice# to XSS injection
Image 2. Script execution

That’s a set of vulnerable to XSS fields in the app. It has no encoding data on output nor has no input validation.

BAC in handling invoice status. Imagine that you had recently closed a kind of really valuable invoice, in fact, for a big amount of money. Its change can make quite a lot of problems if it’s already paid and not intended for further modification. Believe it or not, it’s quite easy to do if you have access to control invoice information before it comes paid. Here are steps to reproduce BAC in handling invoice status:

  1. Admin marks the absolutely normal invoice as “paid” (see img. 3) with POST request like this (we can intercept this by Burp Suite Community Edition (which is free) for example) (see img. 4):
  2. Return to the browser and see how your invoice is now marked as “Read only” (see img. 5).
  3. Back to the Burp Suite and go to the “Repeater” section.
  4. Change invoice_status_id in request’s parameters from 4 to 1 (see img. 6) and then send it.
  5. Return to the browser and see that invoice is still marked as “Read only” but now it’s a draft and we have the option to delete it (see img. 7). (If we click it, it successfully deletes)
    Note: we can change not only the invoice_status_id parameter through this BAC but, for example, the invoice_number parameter (we can put in it XSS injection for instance).

BAC in handling access to draft invoices. The third issue appears from the guest’s side. Guest (Read-Only) users can access drafts of their clients’ invoices while meant to have access only to paid and opened ones.
Step to reproduce this issue is quite easy: we need to go by the link with the invoice_id that we can enumerate http://{domain}/index.php/guest/invoices/view/{invoice_id that in draft} and see info about an invoice that we should not be able to see.

That’s all with it and we wish you enjoy the rest of your day!

LL advises all the researchers to avoid breaking real applications illegally. This fun leads to broken businesses and lives, and, most likely, will not make an attacker really rich.