php injection jak się ustrzec

Jak sie przed tym ustrzec. Nie chodzi mi o bazy danych. Trzymam dane w plikach. Przesylam formularze i parametry ?id=costam. Jesli chodzi o formularze to staram sie usuwac tagi html przed zapisem i trzymac nazwy i wartosci w cudzyslowach
Mam pliki .htaccess. Cos jeszcze??

Trzymam dane w plikach.

Tak jak każda istniejąca nie-memory-only baza danych ;-)

Jesli chodzi o formularze to staram sie [...] trzymac nazwy i wartosci w cudzyslowach

Co to znaczy?

Mam pliki .htaccess.

W jaki sposób .htaccess zabezpiecza Cię przed atakami typu xxx injection?

Cos jeszcze?

Na pewno pomocne jest niewynajdywanie koła od nowa - jeśli (poprawnie!) korzystasz z mechanizmu szablonów (typu Twig czy Blade), jesteś w dużej mierze zabezpieczony.

Frameworki (jak Symfony czy Laravel) również dużo załatwiają za Ciebie i gwarantują pewien stopień bezpieczeństwa, np. dzięki wbudowanym mechanizmom CSRF czy zabezpieczeniami przed SQL Injection poprzez wykorzystanie query builderów, zamiast ręcznego sklejania SQLi.

Na temat odpisuj w postach;

ochroni katalog z plikami gdzie trzymam dane

Nie powinieneś trzymać prywatnych danych w publicznym katalogu - rzuć okiem, jak robi to np. Laravel.

Ktos jeszcze ma pomysły w jaki sposob zabezpieczyć sie ?

Przed czym?

W takim razie gdzie trzymac pliki jak nie w katalogu. Skad kos wie czy bedzie wiedzial znal scuezke do katalogu
Przed czym? Przed wszystkim co może zrobić kuku

W takim razie gdzie trzymac pliki jak nie w katalogu.

1. Przytoczyłeś tylko fragment mojego zdania, przez co straciło ono sens - napisałem: nie powinieneś trzymać prywatnych danych w PUBLICZNYM katalogu.

2. Wspomniałem: rzuć okiem, jak robi to np. Laravel.

Przed wszystkim co może zrobić kuku

Web application security to bardzo szeroki temat - na początek wystarczy, abyś rzucił okiem na owasp top 10.

Jakbym jeszcze wiedzial na co mam patrzec to by bylo dobrze skoro sam nie znam tematu. Jak nie publiczny to jaki. Proste pytanie.

Prywatny...?
Jak spojrzysz na strukturę, którą buduje m.in Laravel czy Yii2, to zobaczysz, że struktura wyraźnie się rozdziela na zasoby publiczne, dostępne dla użyszkodnika - pliki html, cssy itp. oraz zasoby prywatne, do których użytkownik dostępu nie ma i nie będzie wiedział, że w ogóle istnieją w danym miejscu na dysku, bo dostanie albo 403 albo 404 przy próbie wejścia.

Staraj się też czytać to co piszesz, bo robisz to strasznie chaotycznie i niełatwo jest odgadnąć co masz na myśli patrząc na poszczególne pytania czy stwierdzenia.

Dobrze dobrze ale skoro nikt nie zna struktury drzewa czy zwac inaczej skryptu i nie wie gdzie sa trzymane pliki to w jaki sposob to zrobi tzn dostanie sie do katalogu. Moge go tak zakopac ze sam nie bede wiedzial gdzie jest

@wesoly_pogrzeb: wiesz co to jest document/web root (mówię w kontekście serwera www)? Tak jak @Patryk27 przejrzyj jak to robi laravel, albo inny framework). Ale możę opiszę Ci to w skrócie:

1. Serwer www wystawia folder do którego jest dostęp z zewnątrz (czyli przez url w przegladarce) - folder np "public_html"
2. Plik index.php w tym folderze ma dostęp do nadrzędnego folderu i tego co leży obok "public_html" czyli np "application"
3. Aplikacja ma dostęp do tych prywatnych folderów, a użytkownik z zewnątrz tylko do tego co jest w public_html.

Podczas konfiguracji serwera (Apache / nginx) możesz wybrać katalog, gdzie znajduje się kod Twojej aplikacji - zwyczajowo jest to np. /var/www/html/my-application (z plikiem index zlokalizowanym w /var/www/html/my-application/index.php).

Jest to katalog publiczny, gdyż każdy znajdujący się w nim plik jest potencjalnie widoczny dla użytkowników (pomijając kwestię .htaccess).

Początkujący często wrzucają cały kod swojej aplikacji (wraz z konfiguracją) do tego jednego, publicznego katalogu i "zabezpieczają się" poprzez odpowiednie reguły w .htaccess, co ma parę wad - np. .htaccess może zawierać błędy i ostatecznie nie zabezpieczać wszystkiego, co powinien.

Innym, bezpieczniejszym podejściem jest podział aplikacji na część publiczną (tam, gdzie są assety, czyli pliki .js oraz .css) oraz część prywatną (tam, gdzie znajduje się główny kod aplikacji); jeśli spojrzysz sobie na przykładową aplikację w Laraverze (https://github.com/laravel/laravel) zauważysz, że składa się na nią wiele katalogów, między innymi:

• app,
• config,
• public.

Serwer skonfigurowany jest tak, że wskazuje na katalog public, w którym znajduje się tylko plik index.php oraz assety - reszta kodu aplikacji jest poza katalogiem publicznym, w app.

Dzięki takiej strukturze katalogów użytkownicy nie mają w ogóle możliwości odczytać konfiguracji bądź kodu aplikacji, ponieważ znajdują się one w całości poza katalogiem publicznym.

Aplikacja sama w sobie może za to bez problemu się do plików spoza katalogu publicznego odnosić - grunt w tym, że użytkownicy wprost nie mają takiej możliwości.

Dlatego w takich przypadkach zakładasz scenariusz pesymistyczny i zakładasz, że użytkownik wie do jakich zasobów się dostać, zamiast lecieć po linii najmniejszego oporu z uśmiechem jak małpa na widok sera.
W najprostszym przypadku odpowiednie ustawienie .htaccess już blokuje dostęp fizyczny z poziomu przeglądarki do zasobów, na które ustawisz brak dostępu, ale to nie jest wszystko, co można zrobić.
Niestety za dużo z czasów PHP nie pamiętam już na chwilę obecną, więc dokładnej pomocy nie udzielę.

Ponadto wyżej już Ci kolega Patryk podpowiedział gdzie rozpocząć poszukiwania, im więcej będziesz czytał, tym więcej odkryjesz ciekawych mechanizmów i pomysłów na dostanie się przez ludzi dokładnie tam, gdzie ich nie chcesz, toteż zachęcam do podjęcia lektury.

https://www.google.pl/search?rlz=1C1PRFI_enPL786PL786&ei=cKiDW7DZPOGDrwSqo574CA&q=securing+php+scripts+from+access&oq=securing+php+scripts+from+access&gs_l=psy-ab.3..33i22i29i30k1j33i10k1.3785.5766.0.5876.12.11.0.0.0.0.238.1494.0j5j3.8.0....0...1c.1.64.psy-ab..4.7.1354...0i22i30k1.0.iFFWeX2Z7cU

Proszę, sporo wyników będzie przydatnych.

Dziekuje @Patryk27 za odpowiedz ktora mnie juz naprowadzila conieco. Rozumiem ze katalog prywatny ma miec jakies chmody ? bo inaczej tego nie widze. Nie ma fizycznie mozliwosci przejscia katalog wyzej jak public_html

Katalog prywatny nie musi mieć żadnych specjalnych chmodów - jeśli masz następującą strukturę katalogów:

• /var/www/my-application,
• /var/www/my-application/app,
• /var/www/my-application/public.

I ustawisz /var/www/my-application/public jako swój katalog publiczny (inaczej: web root, directory root), to już dzięki takiemu rozmieszczeniu katalogów użytkownicy nie będą mieć dostępu do /var/www/my-application/app (ponieważ znajduje się on poza web root).

Sugeruję, abyś odpalił jakiś serwer HTTP (Apache / nginx), przygotował taki minimalistyczny zestaw katalogów u siebie i sprawdził, jak ta magia działa ;-)

Czyli inaczej mowiac mam public_html a w nim plik index i dwa katalogi public i app

Popraw jesli sie myle

Mylisz się - masz mieć taką strukturę
Folder z wszystkimi plikami/katalogami

• application
  -- tutaj masz całą logikę appki, szablony itp itd,
• public/public_html
  -- tutaj masz index.php i wszystko co jest możliwe do zassania przez usera (np css'y, js'y)

Po raz kolejny napiszę - ściągnij sobie jakiegoś frameworka i sprawdź jak to działa.

Jeśli wrzucisz app do public_html, to nie będzie to żadne zabezpieczenie, bo - uwaga, uwaga - wrzuciłeś kod aplikacji do publicznego katalogu, tak jak brzmi nazwa ;-)

Naprawdę, nie baw się w zgadywanie, tylko odpal u siebie serwer HTTP, przygotuj strukturę katalogów tak, jak Ci poleciłem, i zobacz, jak to działa w praktyce.

No ok ale juz wczesniej napisalem ze nie ma mozliwosci wyjscia z public_html i osadzic tam katalog z programem. Mam mozliwosc poprzez ftp wejsc tylko do public html i tyle

W takim wypadku faktycznie jesteś w prawdopodobnie beznadziejnej sytuacji - najlepiej darować sobie ten "super" hosting za 5 zł rocznie z dostępem tylko po FTP, i wykupić zwyczajny VPS, gdzie będziesz miał dostęp SSH i możliwość konfiguracji środowiska tak, jak Ci się podoba ;-)

Tym niemniej: nikt nie broni Ci odpalić serwera na swoim komputerze, aby móc się pobawić i zobaczyć, co z czym się je.

Chwila bo czegos nie zauwazylem wczesniej. Podczas zalogowania sie na ftp mam taka strukture:

1. katalog ".appdata"
2. Katalog ".php"
3. Katalog "spamassasin"
4. Katalog "applications_backups"
5. Katalog "domains"
6. Katalog "imap"
7. Katalog "Maildir"
   Dwa pierwsze mają przedrostek w postaci ktopki.

Kiedy otworze kat "domains" są tam dwa katalogi. Pierwszy to nazwa konta pod ktorym sie zarejestrowalem a drugi to nazwa domeny .pl i tam sa kolejne katalogi

htpasswd, avstats, logs, public_ftp, public_html, stats
Po otwarciu public_html jest wszystko czyli cala strona. Teraz pytanie. Cxy mam utworzyc katalog dodatkowy z danymi moimi i gdzie majac taka strukture?

Czyli masz dobrze, zaraz obok folderu public_html tworzysz np application i tyle. Będąc wewnątrz public_html możesz na pewno odwołać się do katalogów, które są wyżej.

ja od takich akcji mam codeignitera, działa wszędzie łącznie z php 5.6, wrzucasz paczkę do public_html, rozpakowujesz i działa, masz zabezpieczenia przed atakami, autoryzację, walidację, szyfrowanie itp.

Ok @axelbest. Sprawdze jak wejde na kompa bo teraz z telefonu pisze. Dam znac a jak na razie dziekuje wszystkim ktorzy odpowiedzieli dotychczas

Ok. Wiec kluczowe pytanie:

Co teraz z dostępem do plików.

1. w ogóle ma tam nie być index.php/html ? Chodzi o publiczny czy w pliku index.php przekierowac do tego prywatnego katalogu i ta mma byc jeszcze jeden index.php. ?
2. Przekierowac domene na katalog prywatny a w nim ma byc index.php ?
   Co nalezy teraz zrobic.

Oj... coraz dziwniejsze te Twoje pytania. O jakim htmlu Ty piszesz? Pisz poprawnie, bo widząc index.php. nie wiem czy tam jest literówka czy piszesz na serio.
Po raz kolejny powtórzę - zobacz jak to robią frameworki - sprawdź to sobie na localhoście i tyl, bo teraz za przeproszeniem "męczysz bułę" pytając co rusz o jakieś dziwne rzeczy.

Pytanie jest konkretne. Mam przekierowac domene na ten katalog prywatny czy w pliku index.php zrobic przekierowanie do katalogu prywatnego. Tylko i tak domene bede musial przekierowac.
Prosto się mowi jak się wie. Dla mnie to jest pytanie kluczowe.

Ale otrzymałeś już odpowiedź, zaciągnij dowolny framework i zobacz jak to działa...
I jest konkretne, ale nie ma sensu z punktu widzenia osoby, która już coś robiła, bo kombinujesz jakoś naokoło i nie masz pojęcia jak temat ugryźć, co rozwiązałoby zajrzenie... Do dowolnego frameworka. Serio, mniej byś się denerwował i dawno już byś miał odpowiedź, gdybyś zrobił tak, jak Ci ludzie doradzają ;)

Nosz qfa. Jesli zostawie plik index.php w katalogu publicznym a wszystko czyli cala reszte wsadze w katalog nadrzędny nie będący w katalogu publicznym to jak ma to dzialac. Mam linki kierowac > do katalogu nadrzednego ? Zaraz zglupieje

Synu złoty... Jak Ty piszesz te skrypty?
Jest to pisane obiektowo, używająć MVC/MVVM/etc. czy działasz na kolejnych include'ach skryptów, które są pisane proceduralnie i lecisz po kolei, traktując je tak samo jak htmle?

Bo jeśli piszesz obiektowo, to żadnych linków nie przekierowujesz, tym się zajmują skrypty właśnie, a dokładniej jakiś router/front controller, który obsługuje request.
To co piszesz natomiast brzmi jakbyś miał plik .php dla każdej podstrony z jakimiś jej skryptami. W takim przypadku ta separacja niespecjalnie dobrze będzie chciała działać i najpierw musisz się zająć obiektówką, coby pisać jak cywilizowany człowiek :P

Także... Jak chcesz bardziej rozjaśnić sytuację, to pochwal się fragmentem kodu, bo naprawdę nie wiemy co Ci chodzi po głowie i zaraz wszyscy dostaniemy zajoba :)

Klojtex napisał(a):

Nosz qfa. Jesli zostawie plik index.php w katalogu publicznym a wszystko czyli cala reszte wsadze w katalog nadrzędny nie będący w katalogu publicznym to jak ma to dzialac. Mam linki kierowac > do katalogu nadrzednego ? Zaraz zglupieje

Synu złoty... Jak Ty piszesz te skrypty?
Jest to pisane obiektowo, używająć MVC/MVVM/etc. czy działasz na kolejnych include'ach skryptów, które są pisane proceduralnie i lecisz po kolei, traktując je tak samo jak htmle?

Bo jeśli piszesz obiektowo, to żadnych linków nie przekierowujesz, tym się zajmują skrypty właśnie, a dokładniej jakiś router/front controller, który obsługuje request.
To co piszesz natomiast brzmi jakbyś miał plik .php dla każdej podstrony z jakimiś jej skryptami. W takim przypadku ta separacja niespecjalnie dobrze będzie chciała działać i najpierw musisz się zająć obiektówką, coby pisać jak cywilizowany człowiek :P

Także... Jak chcesz bardziej rozjaśnić sytuację, to pochwal się fragmentem kodu, bo naprawdę nie wiemy co Ci chodzi po głowie i zaraz wszyscy dostaniemy zajoba :)

Nie nie pisze obiektowo.

To napisz dokładnie jakie konkretne dane/rzeczy chcesz ukrywać przed niepowołanym dostępem?