p

Jak nie OVH, to jedynie 100TB.

Skoro najlepiej, to dlaczego nie pochwalisz się, że to u Ciebie?

Dziwisz się? Jesteś typem klienta, którego należy unikać

...o ile dysk będzie zaszyfrowany, w przeciwnym wypadku osoba, która dostanie serwer dedykowany lub dysk po Tobie, może dostać też Twoje dane

http://www.masternet.pl/?go=regulamindomains

http://www.webhostingtalk.pl/topic/16429-wazna-uwaga-dt-umieszczania-prosb-o-pomoc-w-konfiugracji-serwerow-dns-dla-waszych-domen/

Niby od kiedy w Polsce mamy anarchię?

Od kiedy admin jest uprawniony do oceniania co jest zgodne z prawem a co nie? Zawsze myślałem, ze od tego są sądy i inne organy.

http://www.webhostingtalk.pl/topic/22686-hosting-danych-osobowych-%26%238211;-zgodny-z-wymaganiami-giodo/ AFAIK zwykły hosting współdzielony nie zadowoli GIODO.

Tyle tylko, że w ogromnej większości przypadków maszyna hostingowa jest jako-tako zabezpieczona, natomiast VPS nie jest wcale.

Niby na jakiej podstawie?

Zerknij jeszcze na serwersms.pl. Z polskich dostawców smsapi.pl wygląda w sumie najlepiej, ale SLA na poziomie 99% i serwery poza granicami kraju (OVH) średnio do mnie przemawiają...

Nawet jeżeli takie regulacje istnieją, to miałbyś ogromne problemy z udowodnieniem źródła wycieku.

Pewnie dlatego, że już wygasła?

Tak też można, natomiast jak już sam zauważyłeś, URI nie musi być tożsame z plikiem, tak więc można to rozwiązać w bardziej elegancki sposób za pomocą SCRIPT_FILENAME. Zgadza się. Ja nigdy nie twierdziłem, że skrypciarze PHP tworzą cokolwiek w przemyślany sposób

Ale ja doskonale wiem o co chodzi Natomiast Ty źle zinterpretowałeś podany przeze mnie przykład. Jeżeli struktura będzie wyglądała tak jak w moim poprzednim poście, to URL /index.php będzie obsługiwany przez: location ~ \.php$ { ... fastcgi_param SCRIPT_FILENAME $document_root/scripts/$fastcgi_script_name; ... } a wtedy nie ma możliwości aby PHP wykonało cokolwiek z poza /scripts/. Patrz wyżej

Nie znam tego skryptu, tak więc ciężko mi się na ten temat wypowiadać. Jeżeli w systemie plików struktura skyptu wygląda tak: / |-- /images/ |-- /scripts/ |-- /scripts/index.php `-- /uploads/ to wszystko jest OK. Jeżeli natomiast wygląda tak: / |-- /images/ |-- /uploads/ `-- /index.php to nie jest Tak, sprawdzanie czy dany plik istnieje w systemie jest pewnym rozwiązaniem, ale sprawdza się jedynie w przypadkach, kiedy serwer www ma dostęp do tego samego systemu plików co skrypt PHP. Chyba nie muszę tłumaczyć, że to nie jest idealne rozwiązanie Ale to wymaga przemieszania skryptów perla i PHP Ciche ukrywanie problemu nie doprowadzi do jego rozwiązania.

E? Chyba nie do końca zrozumiałeś na czym ten "błąd" polega. Sama możliwość wgrywania pliku przez użytkownika nie jest tutaj warunkiem wystarczającym. Problemem jest brak jakiejkolwiek separacji kodu wykonywalnego od treści. Że niby na co nie powinien pozwalać? Serwer www przekazuje URL (lub jego część) po FastCGI do PHP. PHP następnie wykonuje skrypt, bazując na danych otrzymanych poprzez FastCGI (co samo w sobie jest już głupie). PHP szuka najlepszego dopasowania, czyli jeżeli jeżeli otrzyma URL w postaci "/pliki/obrazek.jpg/index.php", a taka ścieżka nie istnieje w systemie, to zostanie wykonany "/plik/obrazek.jpg". Tyle. Jeżeli ktoś skonfigurował serwer tak, aby skrypty perla były obsługiwane przez PHP, to zgadza się, można.

Jeżeli ktoś pozwala na wgrywanie plików do katalogu, w którym znajduje się kod wykonywalny lub jego podkatalogów, to sam prosi się o problemy. Powtarzałem to już dzisiaj X razy, ale jak widać muszę jeszcze raz: To nie jest ani błąd nginx'a, ani PHP (per se). To jest błąd po stronie osób projektujących w głupi sposób serwisy internetowe. Inne backend'y (python via wsgi, ruby via rack) nie uruchamiają kodu na podstawie informacji podanych przez zwykłego użytkownika (czyt. URL), tak więc są odporne na ten konkretny atak.

Ma przecież napisane "no option".

Nawet jeżeli Cain&Abel podszył się pod maszynę docelową, to musiałeś dostać monit o złym certyfikacjie SSL. Jeżeli go zignorowałeś to był to Twój błąd.

ATMAN / NASK.

Szukaj firmy z serwerami w: - Londynie i okolicach, - OVH (ping 8ms do podanego przez Ciebie adresu).

Hmmm... A w regulaminie widnieje zapis "Debx.pl zobowiązuje się nieudostępniać danych użytkownika.", nie ładnie Nic nie możesz zrobić. To nie jest już Twój serwis i to czy działa czy nie to nie Twoja sprawa. O zmianie danych na stronie trzeba było pomyśleć wcześniej

Już działa