2015-06-04 6 views
16

Obecnie używam Modernizr na wszystkich moich stronach i okazuje się, że ze względu na sposób jego działania wymagane są style unsafe-inline. Już nie zezwalam na skrypty wbudowane i niebezpieczne ewaluacje. Zastanawiasz się, jakie są zagrożenia bezpieczeństwa związane z obsługą stylów wbudowanych?CSP style-src: "unsafe-inline" - czy warto?

Odpowiedz

19

Dopuszczenie stylów wbudowanych sprawia, że ​​jesteś podatny na "inny XSS". Ataki typu Cross Site Styling.

Pomysł polega na tym, że w miejscach, w których użytkownik może wprowadzić atrybut stylu do dokumentu, może zmodyfikować wygląd strony w dowolny sposób. Wymienię kilka potencjalnych ataków uporządkowanych według rosnącej skali:

  1. Mogą zmienić kolor Twojej strony i sprawić, że będzie wyglądać głupio.
  2. Mogli zmodyfikować tekst swojej strony, dzięki czemu wygląda na to, że mówisz coś obraźliwego, co może obrażać twoich czytelników.
  3. Mogłyby tworzyć treści generowane przez użytkowników, takie jak podany link, które pojawiają się poza normalnymi miejscami, w których użytkownicy oczekują zawartości użytkownika, co sprawia, że ​​wydaje się ona oficjalna. (np. zastąpienie przycisku "Logowanie" w witrynie własnym linkiem).
  4. Korzystając ze starannie spreparowanych reguł stylu, mogą wysyłać wszelkie informacje zawarte na stronie do zewnętrznych domen i narażać lub w inny sposób wykorzystywać te dane w złej wierze wobec użytkowników.

Czwarty przykład, informacje są przeciekły do ​​domen zewnętrznych może być całkowicie zapobiec pomimo unsafe-inline pod warunkiem zapewnienia twoje inne zasady CSP nie pozwalają wszelkiego rodzaju żądanie, aby przejść do domeny niezaufane lub wieloznacznych. Ale pierwsze 3 będzie zawsze możliwe, jeśli przegapisz blokowanie jakiegoś atrybutu stylu.

Mike West zrobił dobry talk na ten temat dla CSSConf kilka lat temu dla kilku innych przykładów.

+0

Hej, miły post, ciekawi mnie jednak, co jeśli jest to aplikacja mobilna (pobrana)? czy byłoby to uważane za zagrożenie? Zakładam, że w tym przypadku będą mogli tylko zadzwonić z własną aplikacją i zrobić dziwne rzeczy z css do swojej aplikacji, lub? – mattias

+0

Czy to będzie aplikacja do wyświetlania w przeglądarce internetowej? Byłby to ten sam wektor ataku, co w przypadku zwykłej zawartości przeglądarki. Nie jest to użytkownik, który atakuje sam siebie, ale raczej zewnętrzna (stąd "Cross-Site") jednostka zmieniająca doświadczenie, które dla nich zaplanowałeś. Może to zostać przechwycone przez trzecią stronę JS/CSS (czy weryfikujesz wszystko, co pakujesz?), Nieprawidłowo odkażoną zawartość lub różne inne wektory, takie jak obrazy, które nie są jeszcze wystarczająco inteligentne, aby właściwie je zrozumieć. – jeteon

+0

Wygląda na to, że w przypadku stron z wordpressem większość motywów nie jest zakodowana tak, aby były zgodne z CSP, dlatego musisz używać niebezpiecznych danych inline, unsafe-eval, a nawet danych: w przeciwnym razie cała twoja strona będzie wyglądać okropnie. Rozumiem, że używanie niebezpiecznego inline i niebezpiecznego ewaluumu może otworzyć cię na ataki XSS: "X-XSS-Protection \t 1; mode = block" nie pomogło już w tym? Wygląda na to, że autorzy wtyczek i wordpressów mają wiele do zrobienia, aby ich treść była zgodna z CSP. – MitchellK