tło
Kontraktowano mnie, aby pomóc firmie w utrzymaniu serwera. Pracuję nad niektórymi mniejszymi projektami PHP, ale również sprawdzam problemy z wydajnością, a ostatnio skanuję dzienniki w poszukiwaniu hakerów.
Ci faceci już od jakiegoś czasu pracują nad swoim serwerem i mają to, co nazwałbym starszą aplikacją. Wykorzystuje magiczne cytaty, zmienne globalne (które pozwalają $idna zastąpienie $_GET['id']), używaj .htaccess jako ich jedynego zabezpieczenia w niektórych przypadkach, jak go nazywasz. Koszmar bezpieczeństwa i programowania.
Zostaliśmy zhakowani w przeszłości, głównie za pomocą zastrzyków SQL, które uruchamiałyby SLEEP(99999999)polecenia i działały jak atak DOS. Na szczęście nie prowadzili „małych stołów bobby”,
XKCD: http://xkcd.com/327/
Ponownie napisałem ich wrażliwe instrukcje SQL z mysql_query()(nie mysqli) do transakcji PDO. Analizuję również zapytania dotyczące SLEEPi UNION, których nie używamy, ale zastrzyki mają. Jak na razie dobrze.
Ostatni numer
Ostatnio powiedziano nam, że rekordy w DB zmieniają się dla użytkowników, takie jak ich adresy e-mail na te przypuszczalnie utworzone przez spamerów.
Zauważyłem, że ich kolumny nie mają last_modifiedkolumny, więc nie byliśmy nawet w stanie wiedzieć, kiedy zostały zmienione, nie mówiąc już o kim. Dodałem tę kolumnę, ale to zaledwie pierwszy krok.
Kiedy zaglądałem do tego stołu, zauważyłem, że hasła nie były solone ani nawet mieszane, tylko zapisane jako zwykły tekst.
Komunikacja z klientem
Jak mogę podejść do nich na temat całej sytuacji, jako kontrahenta, bez wymachiwania rękami jak szaleniec? Jakakolwiek rada? Myślałem o spokojnym podejściu,
PROBLEM 1
Streszczenie
Dlaczego to jest problem?
Co może się stać, jeśli nie zostanie to naprawione
Sugerowana poprawka
WYDANIE # 2
Streszczenie
Dlaczego to jest problem?
Co może się stać, jeśli nie zostanie to naprawione
Sugerowana poprawka
Odpowiedzi:
Sugerowane przez ciebie spokojne podejście byłoby najlepsze. Wskazując, że kiedy te dane zostaną ujawnione, większość użytkowników będzie narażona na kradzież tożsamości z powodu ponownego użycia hasła. To byłby dobry moment, aby wskazać, że jest to ten sam problem, który wpłynął na Target (zakładając, że firma nie jest Target). Twój menedżer powinien być bardzo otwarty na zmianę tego.
Jeśli chodzi o zgodność z prawem z danymi, nie uważam, że nazwa użytkownika / hasło są traktowane tak samo jak Dane CC, Dane osobowe itp. Chociaż może to zależeć od tego, jakie informacje posiadasz dla swoich użytkowników. Nie jestem prawnikiem i te aspekty najlepiej byłoby przywołać w twoim objawieniu i powinny zostać przedstawione w dziale prawnym twojej firmy w celu ustalenia legalności.
https://en.wikipedia.org/wiki/Information_privacy_law
I masz ten XKCD, aby ci pomóc:
źródło
To zależy od publiczności, do której próbujesz się z tym skontaktować. Pracowałem w firmach o poważnych problemach z bezpieczeństwem, takich jak ty, ale odmówili tego, dopóki im nie pokazałem.
Jednym z podejść, jeśli jest to wykonalne, jest zestawienie w zasadzie tego, co zamierzasz zrobić, podobnie jak wyszczególnienie tego, co już prawdopodobnie wydarzyło się podczas tych hacków. Jeśli Twoi odbiorcy nie mają charakteru technicznego, prawdopodobnie musisz wskazać koszty biznesowe, jakie mogą ponieść te kompromisy. Oczywiście zhakowane konta zmniejszają wiarygodność systemu i postrzegają wartość produktu przez klientów. Nie wspominając o naruszonym systemie z hasłami i adresami e-mail dla użytkowników, może powodować poważny efekt falowania.
Następną rzeczą, którą powinieneś zrobić, jeśli to w ogóle możliwe, jest udowodnienie tego. Jeśli możesz znieść ten system w środowisku testowym, zrób to. Następnie zademonstruj przed nimi, jaki wpływ możesz mieć na system po stronie klienta aplikacji. Nawet w przypadku ludzi technicznych okazało się to dla mnie dość przekonujące (choć w moich przypadkach zwykle nie działały).
Oczywiście, jak powiedziałeś, musisz wyjaśnić, czy cokolwiek, jakie środki należy podjąć, i oszacować wysiłek, aby to osiągnąć. Pomoże im to uzasadnić koszty, choć niektóre miejsca po prostu i tak się nie przejmą. Przynajmniej możesz oczyścić swoją świadomość i iść naprzód wiedząc, że próbowałeś.
źródło
Jeśli, jak mówisz, masz umowę na utrzymanie ich serwera, z pewnością umowa ta musi obejmować zadania opisu zadań, takie jak zapewnienie integralności, bezpieczeństwa i dostępności systemu operacyjnego, oprogramowania i wszystkich danych itp. ?! Jeśli istnieje nawet niejasna wskazówka, że umowa oczekuje (i pociąga cię do odpowiedzialności) za upewnienie się, że serwer jest bezpieczny, nie marnowałbym czasu na łączenie spraw biznesowych i po prostu wykonałem dobrą robotę, upewniając się, że problemy zostały rozwiązane (biorąc pod uwagę kopia zapasowa przed i po, z zachowaniem historii wersji zmian w kodzie).
Nie spodziewałbym się, że taka zmiana zajmie więcej niż poranny dzień pracy, a jeśli zapytają, nad czym spędziłeś czas, możesz prowadzić dziennik wyjaśniający i uzasadniający twoje działania. Pod warunkiem, że pracujesz w ramach umowy, nie powinno być tutaj żadnych problemów. Czasami doprowadzenie wszystkich do szału bezpieczeństwa przed decydentami powoduje panikę lub, w najgorszym przypadku, stwarza im okazję do powiedzenia, że nie dbają o te problemy, więc nie naprawiaj ich, tymczasem umowa nadal pociąga cię do odpowiedzialności w przypadku naruszenie! Być może nie zawsze jest to podejście najbardziej przyjazne dla biznesu, ale moja etyka zawodowa nie pozwoliłaby mi zostawić niezaszyfrowanych haseł w żadnym systemie, w którym kiedykolwiek byłem odpowiedzialny za zwrócenie na to uwagi.
Z własnego doświadczenia staram się znaleźć za każdym razem, gdy zaczynam pracę dla nowego pracodawcy lub klienta, omawianie z góry scenariuszy i oczekiwań może zaoszczędzić wiele stresu z twojej strony, na przykład: jeśli znajdę jakieś problemy z bezpieczeństwem, które mogę naprawić, czy jesteś zadowolony z żebym kontynuował i ukończył tę pracę, nie przychodząc do ciebie za każdym razem, tylko powiadamiając cię o podejrzewanych naruszeniach / incydentach? Prawie zawsze odpowiedzą na to tak, ponieważ z ich punktu widzenia nie są zainteresowani bezpieczeństwem ani sprzętem komputerowym - dlatego cię zatrudnili! Być może nie odpowiada to na pytanie tak, jak się spodziewałeś, ale mam nadzieję, że daje to do myślenia. Życzę wszystkiego najlepszego i mam nadzieję, że problem zostanie rozwiązany!
źródło
Z pewnością jeśli zmiana adresu e-mail klienta już się dzieje, a to jest uważane za problem - wtedy możliwość zmiany haseł również stanowi problem.
Teraz, jeśli zabezpieczyłeś DB wystarczająco, aby zapobiec temu w przyszłości, to szansa, że każdy może edytować hasło użytkownika, jest podobnie ustalona i musisz tylko rozważyć, czy ktoś może teraz odczytać hasło.
Oczywiście, jeśli mogą, lub jeśli (w mało prawdopodobnym przypadku), że nie całkowicie zabezpieczyłeś DB, to na pewno należy zaszyfrować hasła - jak to zrobić? Po prostu umieść to w tym samym kontekście, co problem „aktualizacji adresów e-mail”. To, czy wymaga to zmiany aplikacji i czy jest to „zbyt trudny” problem, to inna kwestia, którą należy poruszyć z nimi. Spójrz na kod i sprawdź, jaki będzie koszt jego zmiany przed wprowadzeniem sugerowanej poprawki.
źródło