CSV injection

CSV injection, nazywany też formula injection, to podatność polegająca na tym, że serwis umieszcza niezaufane dane w eksportowanym pliku CSV ^[1]. Gdy użytkownik otworzy taki plik w arkuszu kalkulacyjnym, komórka zaczynająca się od określonego znaku zostaje potraktowana jako formuła, a nie jako tekst ^[1]. MITRE katalogizuje tę słabość jako CWE-1236 i wymienia wśród programów, które mogą zinterpretować takie dane, Excel, Numbers i Calc ^[2]. Sam serwis nie wykonuje niczego groźnego; skutki pojawiają się dopiero na komputerze osoby, która pobrała eksport.

Jak działa

Plik CSV to zwykły tekst: wiersze i wartości rozdzielone przecinkami albo średnikami. Nie ma w nim miejsca na informację, czy dana komórka to tekst, liczba czy formuła. Decyzję podejmuje arkusz kalkulacyjny na podstawie pierwszego znaku. OWASP wymienia znaki, od których zaczyna się formuła: znak równości, plus, minus i małpa, a także tabulator, powrót karetki i znak nowej linii; w niektórych ustawieniach regionalnych działają też ich odpowiedniki pełnej szerokości ^[1].

Atak przebiega w dwóch etapach rozdzielonych w czasie. Najpierw atakujący wpisuje spreparowaną wartość w pole, które trafi do eksportu, na przykład w formularzu kontaktowym albo w nazwie konta. Potem administrator pobiera plik CSV i otwiera go w arkuszu. Schemat poniżej pokazuje tę drogę.

RYS. 1Droga formuły od formularza do arkusza

Neutralizację widać na prostym przykładzie. Druga wartość zaczyna się od apostrofu, więc arkusz pokaże ją jako tekst.

imie,wiadomosc
Jan,=SUMA(1;1)
Jan,'=SUMA(1;1)

Zagrożenia i skutki

OWASP opisuje trzy główne scenariusze. Formuła może wykorzystać podatność samego arkusza kalkulacyjnego, może liczyć na to, że użytkownik zignoruje ostrzeżenie o bezpieczeństwie, albo może wyprowadzić dane z otwartego arkusza ^[1]. MITRE jako skutki wymienia wyprowadzenie informacji oraz wykonanie poleceń z uprawnieniami programu arkuszowego ^[2]. Formuły mogą korzystać z hiperłączy i z wiersza poleceń, a nawet uruchamiać całe skrypty ^[2].

• Eksfiltracja danych: formuła odwołuje się do adresu atakującego i dołącza do niego zawartość innych komórek ^[1].
• Uruchomienie programu: Kacper Szurek pokazał, jak mechanizm DDE w Excelu uruchamia zewnętrzny program ^[3], co zbliża skutki do wstrzyknięcia poleceń.
• phishing w arkuszu: formuła może utworzyć link do złośliwej strony, który użytkownik kliknie w zaufanym dokumencie ^[3].

Excel wyświetla ostrzeżenie przed wykonaniem takiego kodu. Szurek zauważa jednak, że wielu użytkowników z przyzwyczajenia albo z niewiedzy zezwala na jego wykonanie ^[3]. MITRE również odnotowuje, że ostrzeżenia w nowszych wersjach Excela ograniczają ryzyko, ale go nie usuwają ^[2]. Atak opiera się więc w dużej mierze na socjotechnice.

Ocena powagi tej klasy błędów jest sporna. OWASP zaznacza, że atak trudno w pełni zablokować i że wiele programów bug bounty wprost wyklucza go z nagradzanych zgłoszeń ^[1]. Szurek podaje, że Google nie traktuje go jako zgłaszalnej podatności, bo użytkownik kontroluje eksport i musi potwierdzić wykonanie kodu ^[3].

W WordPressie

Na stronach WordPress ryzyko dotyczy wtyczek, które eksportują dane wpisane przez odwiedzających: formularzy kontaktowych, list zamówień, zapisów na wydarzenia i list użytkowników. To typowa podatność we wtyczce, bo rdzeń WordPressa nie generuje takich eksportów sam.

Przykładem jest wtyczka WPForms Pro. WPScan opisał błąd CVE-2022-3574: wtyczka nie sprawdzała danych formularza przy tworzeniu eksportu CSV, co mogło prowadzić do CSV injection ^[4]. Poprawka ukazała się w wersji 1.7.7, a zgłoszenie opublikowano 18 października 2022 roku ^[4]. Odwiedzający mógł więc wpisać formułę w formularz, a skutek pojawiał się dopiero przy administratorze, który pobrał zgłoszenia.

WooCommerce stosuje w swoim eksporterze CSV funkcję escape_data(). Jeżeli wartość tekstowa zaczyna się od znaku równości, plusa, minusa, małpy, tabulatora albo powrotu karetki, funkcja dopisuje przed nią apostrof ^[5]. Wartości czysto liczbowe zostawia bez zmian, bo nie mogą utworzyć formuły ^[5]. Tak samo można postąpić we własnym kodzie.

function lab_csv_cell( $value ) {
    if ( is_string( $value ) && preg_match( '/^[=+\-@\t\r]/', $value ) ) {
        return "'" . $value;
    }
    return $value;
}

Jak się bronić

MITRE zaleca trzy kierunki: usunięcie albo zneutralizowanie znaków ryzykownych na początku wartości, poprzedzenie ich apostrofem oraz konfigurację arkusza tak, by nie wykonywał formuł z niezaufanych plików ^[2]. Zastrzega, że skuteczność apostrofu różni się między programami, a ustawienia arkusza użytkownicy często zmieniają ^[2].

OWASP podkreśla, że nie istnieje uniwersalna metoda oczyszczania CSV bezpieczna dla wszystkich arkuszy i wszystkich dalszych odbiorców danych ^[1]. Dlatego obrona powinna być warstwowa:

• neutralizacja przy eksporcie, czyli escapowanie dopasowane do formatu CSV, a nie do HTML;
• sanityzacja danych wejściowych w polach, które z natury nie powinny zaczynać się od znaku formuły, na przykład imię;
• zasada najmniejszych uprawnień przy eksporcie: pobierać dane mogą tylko osoby, które ich potrzebują;
• szybkie wgrywanie łatek wtyczek formularzy i sklepów.

Historia i przykłady

MITRE wymienia jako obserwowane przykłady między innymi CVE-2019-12134, czyli CSV injection przez pola formularza kontaktowego, oraz CVE-2019-17661, wstrzyknięcie formuły przez pola nazwy w systemie zarządzania treścią ^[2]. OWASP przywołuje też CVE CVE-2014-3524 jako przykład błędu w samym arkuszu, który formuła mogła wykorzystać ^[1]. CSV injection należy do tej samej rodziny co XSS (Cross-Site Scripting) i SQL injection: w każdym z tych przypadków dane trafiają do kontekstu, który interpretuje je jako kod.