Piszę zawiłą aplikację internetową w php/mysql/jQuery... a że bezpieczeństwo jest niemal najistotniejsze, to postanowiłem (poza książkową edukacją) wypróbować aplikację w3af.
Przydałyby mi się rady od jakiegoś starego wygi (weterana w3af) co by mi objaśnił, jak skutecznie stosować to narzędzie
Na przekąskę dam takie zagadnienie, co mnie strwożyło (bo wygląda groźnie) i zdziwiło (bo poniższych plików nie widzę przez ftp (nie udaje mi się uruchomić telnet do syf-home.pl)
[sob, 3 lis 2012, 13:01:39] A web backdoor was found at: "http://(...)/simple-backdoor.php" ; this could indicate that your server was hacked. This vulnerability was found in the request with id 866.
[sob, 3 lis 2012, 13:01:39] A web backdoor was found at: "http://(...)/mysql_tool.php" ; this could indicate that your server was hacked. This vulnerability was found in the request with id 868.
(...)
(...)
[sob, 3 lis 2012, 13:01:43] A web backdoor was found at: "http://(...)/cmd.js" ; this could indicate that your server was hacked. This vulnerability was found in the request with id 1031.
[sob, 3 lis 2012, 13:01:43] A web backdoor was found at: "http://(...)/0wn3d.c" ; this could indicate that your server was hacked. This vulnerability was found in the request with id 1030.
Tak więc wykryło 168 backdoors, które nie mogę przez ftp znaleźć... czy to możliwe, żeby były jawne jedynie przez telnet? Czy może są to fałszywe alarmy? Jeżeli były włamy, to może odpowiadać za to moja aplikacja, włam przez apache, czy też mógł zostawić mój poprzednik? (wcześniej pracował nad aplikacją inny programista - katalog i hasła zostały zmienione)
Sądzę, że w celach edukacyjnych warto by było szerzej "obgadać" w3af. Używanie jest nieco utrudnione przez długie "pauzy", w momencie gdy nie jest napisane, na jakim etapie testowania w3af działa.
Za pomoc z góry dziękuję.
Pojawiły się nowe podejrzane logi, gdy uruchomiłem konfigurację OASP_TOP10:
[sob, 3 lis 2012, 14:18:05] The web application sent a persistent cookie.
[sob, 3 lis 2012, 14:18:05] The following scripts are vulnerable to a trivial form of XSRF:
(...) tutaj ponad 20 adresów URL, z czego 5 plików php i jeden plik js
[sob, 3 lis 2012, 14:18:05] The following scripts allow an attacker to send POST data as query string data (this makes XSRF easier to exploit):
The URL: http://(...)/index.php?view=phpinfo is vulnerable to cross site request forgery. It allows the attacker to exchange the method from POST to GET when sending data to the server.
Czy jeżeli aplikacja jest dedykowana do pewnej branży, umiarkowanej liczby użytkowników, nie są przesyłane inne dane niż marketingowe (numery konta etc.) to czy jest to duże zagrożenie?
sob, 3 lis 2012, 14:19:02] An unidentified vulnerability was found at: "http://(...)/index.php", using HTTP method GET. The sent data was: "do=d'kc"z'gj'"%2A%2A5%2A(((%3B-%2A%60)". This vulnerability was found in the request with id 3579.
[sob, 3 lis 2012, 14:19:02] An unidentified vulnerability was found at: "http://(...)/page10.php", using HTTP method GET. The sent data was: "action=d'kc"z'gj'"%2A%2A5%2A(((%3B-%2A%60)". This vulnerability was found in the request with id 3778.
Powyższe dotyczy starych plików (starej wersji aplikacji) - właściwie, to powinienem zrobić porządek ze strukturą plików. Ale czy są to istotne, dla bezpieczeństwa, luki?
Jak im zapobiec?