Jak najlepiej zaprezentować lukę w zabezpieczeniach zespołu zajmującego się tworzeniem stron internetowych we własnej firmie?

Question

Wyobraźmy sobie następujący scenariusz:

pracować w Big Co. i twoi współpracownicy korytarzem są na deweloperami internetowej dla systemu blog publiczny Big CO, który używają dużo pracowników Big CO i niektóre osoby publiczne . System blogów pozwala na dowolny HTML i JavaScript, a ty powiedziano ci, że był to wybór (nie przez przypadek), ale nie jesteś pewien, czy zdaje sobie sprawę z jego konsekwencji.

Więc chcesz przekonać ich, że to zły pomysł. Piszesz jakiś kod demonstracyjny i umieszczasz skrypt XSS we własnym blogu, a następnie piszesz posty na blogu. Wkrótce główny administrator bloga (w hali) odwiedzi Twój post na blogu, a XSS prześle Ci pliki cookie. Kopiujesz je do przeglądarki i jesteś teraz zalogowany jako on.

Dobra, teraz jesteś zalogowany jako ... I zaczynasz rozumieć, że być może nie był to dobry pomysł, aby przejść do "zhackowania" systemu blogów. Ale jesteś dobrym facetem! Nie wchodzisz na jego konto po zalogowaniu się i na pewno nie planujesz opublikować tej słabości; może po prostu chcesz pokazać im, że społeczeństwo jest w stanie to zrobić, aby mogli to naprawić, zanim ktoś złośliwy zda sobie z tego sprawę!

Jaki jest najlepszy sposób działania z tego miejsca?

Answer 1

Ilekroć widziałem problem bezpieczeństwa, który musiał być rozwiązany przez nasz wewnętrzny zespół IT w przeszłości, po prostu mówię im, czym jest problem i co można zrobić, aby go wykorzystać.

W zależności od tego, jak wrażliwi są i jaki jest ich stan z nimi/firmą, kod proof-of-concept może nie być dobrym pomysłem. Jeśli mają powody, by podejrzewać cię o złośliwe używanie, zatrzymam to dla siebie. W przeciwnym razie, jeśli by to docenili, podziel się tym.

To jedyny delikatny obszar. Po prostu przekazuj kwestię odpowiedzialnie w taki sposób, aby było jasne, że jesteś po prostu zaniepokojony kwestiami bezpieczeństwa i nie chciałeś ich wykorzystać.

Answer 2

naprawdę zależy od pozycji w firmie, charakteru ludzi korytarzem, itd. Itd ....

Aby przedstawić jedną opcję:

Podchodzę do nich opisać zagrożenia w kategoriach abstrakcyjnych ("ktoś może przejąć twoje ciasteczka, które z kolei ...") i zapytać, czy chciałby zobaczyć demonstrację? Jeśli w grze są wielkie ego i naprawdę chcesz, żeby to naprawili, nie rozmawiaj z całą drużyną, tylko z szefem zespołu.

Jeśli się zgodzą, poczekaj kilka godzin, a następnie zaloguj się jako "on" i zrób coś nieniszczącego, ale zauważalnego w systemie - zrobiłeś to za ich zgodą. Prawdopodobnie będą pod wrażeniem i dopilnują, aby dziura została naprawiona.

Jeśli się nie zgadzają i mówią, że odejdziesz, cóż, będziesz musiał rozważyć swoje opcje: Albo weźmiesz je gdzieś wyżej, albo zakopujesz. Wspominając o problemie, zrezygnowałeś z wszelkich opcji wysyłania go anonimowo.

Jeśli nie możesz być w 100% pewny, że wszyscy w łańcuchu decyzyjnym jest rozsądny i całkowicie rozumie, co robisz, i że jest to dla dobra firmy, nie zrobiłbym żadnego nieuczciwego "hakowania" "- zawsze mówić o tym pierwszy, szczególnie w dużym środowisku firmy.Te rzeczy są zbyt łatwe do zinterpretowania jako złośliwe na twoim końcu - szczególnie, jeśli jest ktoś, kto będzie zawstydzony budowaniem tej luki bezpieczeństwa i chciałby obwinić kogoś innego.

Answer 3

Wszyscy koncentrują się na naprawianiu problemu z witryną internetową, a może jestem po prostu trochę makiawelicznym, ale myślałbym również o upewnieniu się, że moje zastrzeżenia zostały zapisane na piśmie; Napisałem maila do kilku moich przełożonych.

Ostatnią rzeczą, jakiej potrzebujesz, jest strona, którą chcesz wykorzystać, a decydent przychodzi, nalegając, że to twoja praca (lub praca twojego kumpla), aby rozważyć tę techniczną stronę, a ty odkrywasz, że nikt nie pamięta, że ​​się odezwałaś.

Answer 4

Myślę, że przekroczyłeś swoją rolę. Chociaż luki w zabezpieczeniach XSS są poważnym problemem, jeśli nie zajmujesz się rolą bezpieczeństwa informacji w swojej organizacji, naprawdę nie masz intruzów dotyczących sposobu, w jaki działa organizacja rozwoju w hali.

Nie ma czegoś takiego jak absolutne bezpieczeństwo, ale wyobrażam sobie, że ludzie nadzorujący projekt blogu odpoczywają w nocy, wiedząc, że jeśli jakikolwiek pracownik nadużywa technologii, może być śledzony w dziennikach i odpowiednio do tego traktowany.

Jeśli napisałeś złośliwy kod "do demostracji tego" bez ich zgody, jest to dość poważna akcja, którą możesz podjąć bez zgody i wyobrażam sobie, że twoi przełożeni czuliby się tak samo.

Answer 5

Masz trzy możliwości: żywotne

1. rozmawiać z zespołem internetowej.

2. Porozmawiaj ze swoim własnym szefem.

3. Zignoruj ​​to.

myślę pójdę zarówno 1 i 2.

Answer 6

To jest niepokojące zachowanie. Jeśli nie rozumieją najprostszych wad bezpieczeństwa, takich jak XSS, muszą one być zwolnione. Nie jest to spowodowane pojedynczą luką, to po prostu głupota. Powinni zostać zwolnieni, ponieważ nie rozumieją bezpieczeństwa i nie mam wątpliwości, że wprowadzili do systemu bardziej surowe luki w zabezpieczeniach. Jeśli nie otrzymają tego podręcznika XSS, to co z CSRF? Będą myśleć, że jesteś szalony!

Zrozumienie wpływu kodu na bezpieczeństwo jest bezwzględnym wymogiem. Bez tego programista jest tylko odpowiedzialnością.