jak widać powyżej, kod daje błąd „Exception in thread „main” java.lang.ClassCastException: testserialization.ExploitDeser nie może być użyty do testowania.Employee”, co oznacza, że typ-casting nie jest właściwy, jednak kod nadal jest wykonywany. Funkcja readObject klasy DeserializeDemo jest w stanie wykonać niestandardową implementację readObject klasy ExploitDeser.,
To jest to, co jest niebezpieczne deserializacja tutaj, że nawet jeśli istnieje błąd odlewania typu nadal jeśli serializowane dane niestandardowej klasy z niestandardową implementacją readObject są dostarczane jako dane wejściowe, to jest wykonywane jak pokazano powyżej.
To właśnie robią łańcuchy gadżetów używane przez ysoserial i inne narzędzia do deserializacji Javy, gdzie szukają łańcuchów klas, aby ostatecznie wylądować w niestandardowej implementacji readObject, która może wykonać kod na poziomie systemu dostarczony jako część wejścia użytkownika.,
remediacja
teraz, gdy przyjrzeliśmy się, czym jest Deserializacja i jak jest wykorzystywana, spójrzmy na remediację do tego.
remediacja, którą tutaj omówimy, nazywa się „look-ahead class validation”, gdzie możemy dodać listę klas, które chcemy deserializować. Na przykład. w naszym scenariuszu spodziewamy się, że tylko Dane obiektów klasy pracowniczej będą deserializowane, a pozostałe nie powinny zezwalać na deserializację.,
tak więc, zasadniczo to, co robi ta metoda, to nadpisanie funkcji „resolveClass”, która jest częścią klasy”ObjectInputStream” (używanej podczas deserializacji) i wykonuje białą listę listy klas, które muszą być deserializowane.
teraz, gdy skończyliśmy z teorią, przejdźmy do implementacji.,
pozwala utworzyć nową klasę „LookAheadObjectInputStream” rozszerzyć ją do klasy ObjectInputSteam, tak abyśmy mogli nadpisać funkcję member resolveClass:
w powyższym kodzie linia:
if (!desc.getName().equals(Employee.class.getName())) {
zasadniczo szuka, jeśli serializowana zawartość zawiera obiekt klasy Employee, w przeciwnym razie wyświetla błąd „nieautoryzowana próba deserializacji” i uniemożliwia jej wykonanie.,
teraz, ostateczny zmodyfikowany kod dla „DeserializedDemo” jest jak pokazano poniżej:
w powyższym kodzie obserwuj podświetlony kod, w którym zamiast wywoływać klasę objectinputstream, wywoływana jest klasa lookaheadobjectinputstream, która nadpisuje metodę resolveclass podczas wykonywania i odpowiednio ją wykonuje.
teraz przejdźmy do złośliwości.,ser plik utworzony wcześniej jako wejście do deserializacji i obserwować wyjście:
jak widać powyżej, tym razem niestandardowa implementacja readobject z klasy custom „exploitdeser” nie jest wykonywana podczas deserializacji., Zamiast tego otrzymujemy niestandardowy komunikat o błędzie „nieautoryzowana próba deserializacji”, który został ustawiony w nadpisanej funkcji resolveClass w klasie LookAheadObjectInputStream.
jest to bardzo prosty przykład użycia metody sprawdzania poprawności klasy look-ahead, aby zapobiec Niezabezpieczonej deserializacji. Obszerną implementacją wokół tej idei jest biblioteka „serialKiller”. Link można znaleźć poniżej:
dlatego można to uznać za jedno z rozwiązań łagodzących niepewną deserializację w Javie.,
nadal szukam innych metod łagodzenia, o których będę pisał później.
proszę o cenne uwagi. Do tego czasu hakowanie i uczenie się….
