Dowód na to, że SharePoint nie ma usterek SQL Injection?

Question

Moja firma ma wymóg, aby wszystkie zakłady produkcyjne przesłały skan bezpieczeństwa aplikacji AppScan. Czasami, gdy skanujemy instalację SharePoint, oprogramowanie wykrywa podatność na słaby incydent SQL. Jestem prawie pewien, że jest to fałszywy alarm - AppScan prawdopodobnie interpretuje inną aktywność w odpowiedzi HTTP jako sukces niewidomego wtrysku. Ale trudno to udowodnić.

Podejrzewam, że SharePoint, zarówno MOSS 07, jak i WSS 3.0, wykorzystuje procedury przechowywane wyłącznie za kulisami. Czy ktoś wie, czy istnieje jakakolwiek dokumentacja od Microsoft w tym celu, a ponadto czy którakolwiek z procedur przechowywanych używa dynamicznie generowanego kodu SQL? Gdyby wszystko było sprochem, a żadna z nich nie byłaby dynamiczna, mielibyśmy niezłe dowody na to, że SharePoint nie ma podatności na iniekcje SQL.

Answer 1

Nie wszystkie są przechowywane proc. W szczególności takie rzeczy, jak połączenia z listami krzyżowymi, tworzą okropną składnię. Na przykład spójrz na okno śledzenia SQL z this article. Ponadto, ponieważ zarówno kontrolki użytkownika, jak i wywołania interfejsu API mogą być pisane przez programistów, nie ma gwarancji, że nie będą podlegać iniekcji SQL, jeśli używasz modułów niestandardowych.

Domyślam się, że SharePoint zawsze używa przynajmniej nazwanych parametrów. Jednak najlepszą opcją może być wykonanie śledzenia SQL i porównanie wyników. Ponadto, jeśli jesteś wystarczająco dużym klientem, możesz po prostu spróbować zadzwonić do lokalnego ewangelisty MSFT (lub zamieścić pytanie na stronie connect.microsoft.com) i sprawdzić, czy możesz uzyskać odpowiedź.

Answer 2

Dzięki. Spojrzałem na profilera i znalazłem kilka rzeczy: Wygląda na to, że SharePoint wykonuje tylko procedury składowane. Występują sporadyczne fragmenty czystego kodu SQL, ale wydaje się, że są one ograniczone do "exec sp_oledb_ro_usrname" i "select collationname (...)", które wydają się być głęboko wewnętrzną rzeczą i prawdopodobnie nie są wykonywane jako SQL w wszyscy, ale po prostu wychodzą w profiler w ten sposób ...?

SharePoint czasami korzysta ze sp_executesql, ale jest to wywołanie sparametryzowane i dlatego prawdopodobnie nie jest wstrzykiwane.

Answer 3

Istnieje wiele stosunkowo nowych ślepych wektorów wstrzykiwania SQL opartych na opóźnieniu odpowiedzi - na przykład przy użyciu WAITFOR DELAY. Przynajmniej sqlmap i BurpSuite używają ich (a także innych prawdopodobnie).

Wektory te są jednak podatne na fałszywe alarmy, ponieważ wyzwalaczem jest, no cóż, opóźnienie odpowiedzi HTTP, które może się również zdarzyć z tysięcy innych powodów, jeśli skanujesz przez Internet. Jeśli dostałeś je za pośrednictwem sieci LAN, byłbym bardziej podejrzliwy, ale mimo to zbadam inne możliwe przyczyny opóźnień po stronie serwera. Tylko jeśli otrzymasz opóźnienie konsekwentnie w wielu niezależnych próbach, prawdopodobnie masz do czynienia z luką.

Należy również zauważyć, że SharePoint często uruchamia stare luki FrontPage w wielu skanerach wulgarnych, które są również fałszywie dodatnie - po szczegóły zobacz ten artykuł "SharePoint and FrontPage Server Extensions in security scanner results".