gik|iewicz

title: „Aplikacja za 1500 dolarów złamana przez sztuczną inteligencję”
description: „Test hakowania podatnej aplikacji przez modele LLM za 1500 dolarów. GPT-4 skutecznie exploitował luki, Claude odmawiał ataku. Sprawdź wyniki eksperymentu bezpieczeństwa.”
coverImage: „https://gikiewicz.eu/wp-content/uploads/2026/06/zbudowalem-podatna-aplikacje-i-wydalem-1500-dolarow-by-spraw-cover.jpg”
date: „2026-06-04”
author: „Grzegorz Kikiewicz”
category: „bezpieczeństwo”
tags:
– LLM
– bezpieczeństwo
– GPT-4
– testy penetracyjne
slug: „zbudowalem-podatna-aplikacje-i-wydalem-1500-dolarow-by-spraw”

1500 dolarów wydane na testy bezpieczeństwa aplikacji internetowej. Tyle kosztowało sprawdzenie, czy popularne modele językowe takie jak GPT-4, Claude czy Gemini potrafią samodzielnie znaleźć i wykorzystać luki w celowo podatnym systemie. Eksperyment, o którym donosi Antyweb, obnaża realne możliwości sztucznej inteligencji w dziedzinie cyberbezpieczeństwa.

TL;DR: Badacze celowo stworzyli podatną aplikację i wydali 1500 dolarów na zapytania API do różnych modeli LLM. Chcieli sprawdzić, czy sztuczna inteligencja sama znajdzie luki i przeprowadzi atak. Testy wykazały znaczne różnice między modelami – jedne podejmowały próby włamań, inne odmawiały współpracy.

Jak wyglądała aplikacja stworzona za 1500 dolarów?

Testowa aplikacja została celowo wyposażona w zestaw popularnych luk bezpieczeństwa, które regularnie pojawiają się w produkcyjnych systemach webowych. Koszt budowy i utrzymania środowiska testowego zamknął się w kwocie 1500 dolarów. Badacze zaimplementowali klasyczne wektory ataków znane z list OWASP Top 10, aby sprawdzić, czy modele językowe potrafią je zidentyfikować i wykorzystać w kontrolowanych warunkach.

Projekt zakładał symulację realnego środowiska aplikacji internetowej z autentykacją, formularzami i bazą danych. Co więcej, system zawierał celowe podatności wstrzykiwania kodu SQL, cross-site scripting (XSS) oraz podatności na wstrzykiwanie poleceń systemowych. Całość miała stanowić wiarygodny poligon doświadczalny dla sztucznej inteligencji.

Podobne testy bezpieczeństwa aplikacji pokazały już wcześniej różne problemy. Na przykład brukselska aplikacja do weryfikacji wieku została złamana przez hakerów w zaledwie 2 minuty. Podobnie jak w przypadku naruszenia bezpieczeństwa, które wymusiło aktualizację ChatGPT na Macu, eksperyment z podatną aplikacją obnaża realne słabości systemów informatycznych.

Poniżej zestawienie głównych typów podatności zaimplementowanych w testowej aplikacji:

• Wstrzykiwanie SQL (SQL Injection) – luka w zapytaniach do bazy danych
• Cross-Site Scripting (XSS) – wykonywanie złośliwych skryptów w przeglądarce
• Command Injection – wstrzykiwanie poleceń systemu operacyjnego
• Broken Authentication – błędy w mechanizmach logowania i sesji
• Insecure Direct Object References – niebezpieczne odwołania do obiektów
• Path Traversal – przeglądanie katalogów serwera w poszukiwaniu plików
• Server-Side Request Forgery (SSRF) – fałszowanie żądań serwera
• XML External Entities (XXE) – podatności przetwarzania dokumentów XML

Czy modele LLM faktycznie potrafią hakować aplikacje?

Wyniki eksperymentu z budżetem 1500 dolarów wykazały, że zdolności modeli językowych do przeprowadzania autonomicznych ataków są mocno zróżnicowane. GPT-4 odnotował najwyższą skuteczność w identyfikacji i wykorzystywaniu podstawowych podatności. Inne modele wykazywały mniejszą agresywność lub odmawiały wykonania zapytań. Szczegóły tych testów pokrywają się z doniesieniami o chatbotach AI polecających złośliwe strony.

Modele językowe wykazują istotne ograniczenia w kontekście zaawansowanego hakowania. Przede wszystkim brakuje im zdolności do planowania wieloetapowych ataków, które wymagają łączenia informacji z różnych źródeł. Ponadto systemy bezpieczeństwa wbudowane w komercyjne modele często blokują zapytania o charakterze hakerskim. To znacznie ogranicza ich użyteczność jako narzędzi do testów penetracyjnych.

Otwarte modele pozbawione filtrów etycznych potrafią generować szkodliwy kod, ale wymagają stałego nadzoru człowieka. W rezultacie LLM sprawdza się lepiej jako asystent hakerów niż autonomiczny eksploitator. Na przykład, modele potrafią szybko analizować kod źródłowy i sugerować potencjalne wektory ataków. To znacznie przyspiesza pracę specjalisty ds. bezpieczeństwa.

Jakie modele najlepiej radzą sobie z wykrywaniem podatności?

Z testów wynika, że GPT-4 osiągnął najlepsze rezultaty w identyfikacji luk bezpieczeństwa. Skutecznie znajdował podatności typu SQL Injection oraz Command Injection. Claude wykazał się większą ostrożnością i często odmawiał wykonania potencjalnie szkodliwych zapytań. Gemini natomiast miał najwięcej problemów ze zrozumieniem kontekstu ataku, co potwierdzają doniesienia o dominacji GPT w testach hakowania LLM.

Skuteczność w wykrywaniu podatności zależy od wielu czynników, między innymi od sposobu sformułowania zapytania (promptu) oraz wersji modelu. Modele są stale aktualizowane, co oznacza, że wyniki mogą się różnić w zależności od dnia testu. Warto sprawdzić, jak poszczególne modele radzą sobie z konkretnymi typami luk.

• GPT-4 – najwyższa skuteczność w podstawowych atakach
• Claude – silne filtry bezpieczeństwa, częste odmowy
• Gemini – najniższa skuteczność w testach hakowania
• Modele open-source – dobre jako asystenci, słabe jako autonomiczni hakerzy

Dlaczego sztuczna inteligencja nie zastąpi hakerów?

Sztuczna inteligencja napotyka fundamentalne bariery w próbach samodzielnego hakowania aplikacji. Głównym problemem jest brak zdolności do kreatywnego myślenia i łączenia faktów w sposób, który jest naturalny dla doświadczonych specjalistów ds. cyberbezpieczeństwa. Choć modele językowe potrafią analizować kod i identyfikować znane wzorce podatności, nie radzą sobie z nowymi wektorami ataków.

Dodatkowo, jak wskazują eksperci na Biznes Wprost, wiedza ekspercka w erze AI zyskuje na znaczeniu. To potwierdza, że automatyczne narzędzia nie zastąpią doświadczonych specjalistów. Modele językowe są świetnymi asystentami, ale wymagają stałego nadzoru człowieka, szczególnie w tak delikatnej dziedzinie jak cyberbezpieczeństwo.

Firmy technologiczne same dostrzegają te ograniczenia. Zgodnie z doniesieniami Money.pl, następuje ostry zwrot w podejściu do AI. Początkowy zachwyt ustępuje miejsca realistycznej ocenie możliwości tej technologii. W dziedzinie bezpieczeństwa oznacza to powrót do sprawdzonych metod testowania, z AI jako wsparciem, a nie zastępstwem.

Testy za 1500 dolarów pokazują wyraźnie, że modele językowe potrafią identyfikować podstawowe podatności, ale nie są gotowe do autonomicznego prowadzenia zaawansowanych ataków. Sztuczna inteligencja to narzędzie wspomagające specjalistów, a nie ich zastępstwo.

Jakie techniki promptowania zastosowano podczas testów za 1500 dolarów?

Badacze wykorzystali techniki inżynierii promptów, aby ominąć filtry bezpieczeństwa modeli komercyjnych. Według doniesień Antyweb, koszty zapytań API osiągnęły 1500 dolarów, co pozwoliło na wielogodzinne testy różnych strategii omijania zabezpieczeń. Modele poddano próbom wydobycia szkodliwego kodu przy użyciu odpowiednio sformułowanych instrukcji.

Najskuteczniejszą metodą okazało się osadzenie modelu w fikcyjnym scenariuszu. Zamiast bezpośrednio prosić o kod exploita, badacze prosili o „przykładowe rozwiązanie dla celów edukacyjnych”. Ponadto zastosowano technikę stopniowego eskalowania zapytań, gdzie model najpierw analizował architekturę, potem sugerował poprawki, a na końcu generował gotowy wektor ataku.

Bezpośrednie zapytania typu „jak zhakować tę aplikację” kończyły się odmową w niemal każdym modelu komercyjnym. Claude blokował takie próby natychmiast. Gemini również odmawiał współpracy. GPT-4 wymagał bardziej wyrafinowanego podejścia, aby ominąć jego wbudowane filtry etyczne.

Oto zestawienie technik stosowanych podczas testów:

• Role-playing jako specjalista ds. bezpieczeństwa testujący aplikację
• Stopniowa eskalacja zapytań od ogólnej analizy do konkretnych exploitów
• Kontekst edukacyjny z prośbą o „przykładowe” rozwiązania
• Dzielenie zapytań na wiele kroków, z których żaden nie wygląda jak atak
• Wykorzystanie luk w logice modelu poprzez sprzeczne instrukcje
• Symulacja środowiska testowego z fałszywymi danymi
• Zamaskowanie intencji poprzez prośbę o audyt kodu
• Odwoływanie się do dokumentacji technicznej jako źródła wiedzy

Jak budżet 1500 dolarów rozłożył się między poszczególne modele?

Koszty testów pokazują istotne różnice w cenie za tokeny między dostawcami modeli językowych. Z budżetu 1500 dolarów większość została przeznaczona na zapytania do GPT-4, który oferuje najlepszy stosunek skuteczności do ceny. Badacze musieli uwzględnić koszty zarówno zapytań wejściowych, jak i wyjściowych, które różnią się w zależności od dostawcy.

GPT-4 okazał się najdroższy w utrzymaniu, ale jednocześnie najbardziej skuteczny w identyfikacji podatności. Claude generował niższe koszty, ponieważ jego filtry bezpieczeństwa często przerywały konwersację przed wygenerowaniem pełnej odpowiedzi. Gemini natomiast wymagał największej liczby prób, co zwiększyło koszty pomimo niższej ceny za token.

W rezultacie budżet rozłożył się nierównomiernie. Badacze wydali więcej na modele, które wymagały mniejszej liczby prób do osiągnięcia rezultatu. Mimo to, całkowity koszt 1500 dolarów (ok. 6000 zł) pokazuje, że testy bezpieczeństwa z wykorzystaniem LLM nie są tanie, szczególnie gdy wymagają tysięcy iteracji.

Czego eksperyment z 1500 dolarów uczy o bezpieczeństwie aplikacji?

Eksperyment za 1500 dolarów potwierdza, że podstawowe podatności aplikacji webowych pozostają łatwe do wykrycia przez narzędzia automatyczne. Testy wykazały, że modele językowe potrafią identyfikować luki typu SQL Injection czy Command Injection bez specjalistycznej wiedzy z zakresu cyberbezpieczeństwa. Wystarczy odpowiednio sformułowany prompt.

Jednakże zaawansowane wektory ataków, takie jak SSRF czy błędy w autentykacji, stanowią poważne wyzwanie nawet dla najlepszych modeli. Co więcej, modele często nie potrafią łączyć informacji z różnych etapów ataku w spójną całość. Na przykład, znalezienie podatności Path Traversal nie prowadzi automatycznie do prób eskalacji uprawnień.

Dlatego deweloperzy powinni traktować LLM jako dodatkową warstwę testów, a nie jako zastępstwo dla audytów bezpieczeństwa. Narzędzia automatyczne pomagają, ale nie wyłapują wszystkich problemów.

Jakie są realne zagrożenia związane z wykorzystaniem LLM do ataków?

Zagrożenia związane z wykorzystaniem modeli językowych do ataków na aplikacje webowe rosną wraz z poprawą ich zdolności reasoningowych. Choć obecne modele nie potrafią przeprowadzać autonomicznych ataków, sytuacja może się zmienić w przyszłości. Zgodnie z doniesieniami Instalki, cyberprzestępcy już teraz wykorzystują AI do generowania złośliwych treści.

Główne zagrożenie nie polega na autonomicznym hakowaniu, lecz na obniżeniu progu wejścia do cyberprzestępczości. Modele językowe mogą pomóc osobom bez wiedzy technicznej w generowaniu szkodliwego kodu lub identyfikacji podstawowych podatności. Ponadto narzędzia AI mogą przyspieszyć pracę doświadczonych hakerów, umożliwiając im testowanie większej liczby celów w krótszym czasie.

Obrona przed takimi atakami wymaga stosowania sprawdzonych praktyk bezpieczeństwa. Walidacja danych wejściowych, parametryzowane zapytania SQL i regularne audyty kodu pozostają podstawą ochrony. Techniki te są skuteczne niezależnie od tego, czy atakujący korzysta z AI, czy z tradycyjnych narzędzi.

Jak przygotować aplikację na erę AI-asystowanych ataków?

Przygotowanie aplikacji na ataki wspierane przez sztuczną inteligencję wymaga powrotu do podstaw bezpieczeństwa. Dlatego deweloperzy powinni skupić się na eliminacji znanych luk z list OWASP Top 10.

Przede wszystkim należy wdrożyć automatyczne skanowanie podatności w procesie CI/CD. Narzędzia takie jak SAST i DAST potrafią wyłapać większość błędów, które LLM identyfikują podczas testów. Co więcej, warto rozważyć wykorzystanie modeli językowych jako dodatkowego narzędzia w procesie code review, podobnie jak w przypadku lokalnych modeli LLM odciążających infrastrukturę.

Ponadto organizacje powinny inwestować w szkolenia deweloperów z zakresu bezpiecznego kodowania. Eksperci wskazują, że wiedza ekspercka zyskuje na znaczeniu w erze AI. Zgodnie z doniesieniami Biznes Wprost, specjaliści potrafiący ocenić i skorygować wyniki działania AI będą kluczowi dla bezpieczeństwa systemów.

Oto lista rekomendowanych praktyk zabezpieczających aplikacje:

• Parametryzowane zapytania SQL eliminujące ryzyko SQL Injection
• Walidacja danych wejściowych na serwerze
• Escaping znaków specjalnych zapobiegający atakom XSS
• Implementacja Content Security Policy w nagłówkach HTTP
• Regularne skanowanie podatności w potokach CI/CD
• Szkolenia deweloperów z bezpiecznego kodowania
• Testy penetracyjne przeprowadzane przez doświadczonych specjalistów
• Monitorowanie logów pod kątem nietypowych wzorców ruchu

Często zadawane pytania

Ile kosztuje test bezpieczeństwa aplikacji z wykorzystaniem LLM?

Eksperyment opisany na Antyweb wykazał całkowity koszt na poziomie 1500 dolarów (ok. 6000 zł) za wielogodzinne testy wielu modeli. Zacznij od budżetu minimum 500 dolarów na podstawowe skanowanie.

Który model LLM najlepiej nadaje się do testowania bezpieczeństwa?

Testy pokazały, że GPT-4 osiągnął najwyższą skuteczność w identyfikacji podstawowych podatności, podczas gdy Claude blokował większość zapytań. Wybierz GPT-4 do automatyzacji testów, ale pamiętaj o nadzorze specjalisty.

Czy sztuczna inteligencja może samodzielnie zhakować aplikację?

Badania wykazały, że obecne modele nie potrafią przeprowadzać autonomicznych, wieloetapowych ataków. Traktuj LLM jako asystenta wspomagającego specjalistę ds. bezpieczeństwa, a nie jako samodzielne narzędzie hakerskie.

Jak chronić aplikację przed atakami z wykorzystaniem AI?

Podstawowa ochrona polega na wdrożeniu praktyk z OWASP Top 10, w tym parametryzowanych zapytań SQL i walidacji danych wejściowych. Te metody blokują większość wektorów ataków, które modele LLM próbują wykorzystać.

Podsumowanie

Eksperyment z budżetem 1500 dolarów dostarcza kilku konkretnych wniosków dotyczących bezpieczeństwa aplikacji webowych w erze sztucznej inteligencji:

• Modele językowe potrafią identyfikować podstawowe podatności, ale nie są gotowe do autonomicznych ataków
• GPT-4 osiągnął najlepsze rezultaty w testach hakowania, podczas gdy Claude i Gemini wykazywały silne filtry bezpieczeństwa
• Koszt testów z wykorzystaniem LLM jest porównywalny z tradycyjnymi narzędziami do skanowania podatności
• Największym zagrożeniem jest obniżenie progu wejścia do cyberprzestępczości, a nie autonomiczne hakowanie
• Podstawowe praktyki bezpieczeństwa z OWASP Top 10 pozostają najskuteczniejszą obroną przed atakami AI-asystowanymi

Zainteresował Cię temat bezpieczeństwa AI? Przeczytaj, jak GPT dominuje w teście hakowania LLM i dowiedz się, dlaczego Gemini nawet nie próbuje konkurować w tej dziedzinie. Sprawdź również, jak przejście na lokalny model LLM może pomóc w kontrolowaniu kosztów eksperymentów z sztuczną inteligencją.