[MySQL][PHP]Metoda na usunięcie rekordu z bazy Opcje

[kaczkazdw]

Witam!

Mam proglem nad którym już trochę główkuję i przeszukuje fora w poszukiwaniu satysfakcjonującej mnie odpowiedzi.

Mamy panel administratora np. i są wyświetlone artykuły na stronie w ładnej tabelce. Na końcu każdego wiersza są dostępne możliwe operacje na hiperłączach, edycja i usuwanie. Niech chodzi mi tutaj o samą edycję co o sposób usuwania. Na samym poczatku napisałem skrypt z wykorzystaniem GET który usuwał artykuł po kliknięciu usun w tym samym wierszu. Oczywiście zauważyłem informacje na pasku adresu z końcówką /delete.php?id=9. Postanowiem sprawdzić, czy wpisując inny numer id w adresie usunie mi inny link. Otóż tak się stało. Więc moje pierwsze pytanie brzmi, jak najlepiej się przed tym zabezpieczyć?

Widziałem też wykorzystanie checkboxów do usuwania wybranych rekordów, wtedy można by było zaznaczyć tylko jeden i z głowy. Wszystko fajnie, tylko wymagane jest, by checkbox znajdował się w formularzu? Będzie działało coś takiego, jeśli tabele obejmę w ramy <form ...> </form> i przy każdym wierszu znajdzie się checkbox?
Ktoś może mi podsunąć pomysł, jak ewentualnie poprawnie wykonać coś takiego? Jakoś trzeba podać dalej, który checkbox jest zaznaczony i przydzielony do danego artykulu.


A może macie jakiś lepszy sposób do usuwania rekordu, w przyjemny i pożyteczny sposób?

Pozdrawiam.

Ten post edytował kaczkazdw 17.09.2012, 19:26:17

[Ulysess]

co do 1 zabezpieczenia , rozumiem że chcesz się chronić przed sobą samym ? skoro masz panel administracyjny to do tego panelu masz tylko Ty bądz zaufane Tobie osoby dostęp wiec w czym problem
co do 1 to wstawiasz typ checkbox z name=id_message[1] -> dla kolejnego będzie name=nr[2] itd , oraz value=1000 gdzie 1000 oznacza id kasowanego posta.

jeśli chodzi już o samo kasowanie to zrób np:

[PHP] pobierz, plaintext 
foreach ($_POST['id_message'] as $id_msn)
{
// tutaj akcja kasowania posta
}
[PHP] pobierz, plaintext 

[kaczkazdw]

No dobrze, wszystko rozumiem.
A powiedzmy, gdybyśmy nie chcieli chronić się już przed nami samymi tylko przed innymi użytkownikami którzy także korzystają z portalu (bo taka była moja ogólna intencja)?
Jak najlepiej zabezpieczyć się przed hax0rami ;] którzy wszedzie wtykają swoje klawiaturki?


Ew. czy da sie wykorzystać w jakiś sposób metodę POST zamiast GET (do mojego pierwszego pytania)? Żeby nie ujawniać tego postępowania tak wyraźnie?

Ten post edytował kaczkazdw 17.09.2012, 19:54:40

[viking]

Możesz XHR, dodatkowe tokeny przed CSRF i odpowiedni ACL. Takie dane zawsze kasuje się POST. I akurat nie ważne czy my, czy znajomi zawsze należy zabezpieczyć. Ktoś przez przypadek zyska dostęp i wszystkie dane polecą w kosmos.

[b4rt3kk]

Jak ktoś otrzyma dostęp, to co za różnica jaka metoda została użyta do usuwania? POST czy GET? I tak ma dostęp do całej listy.

Może użyj Ajaxa? Wtedy kasowanie będzie się odbywało bez przekierowania na kolejną podstronę. Tak czy siak, jak ktoś się włamie, to nie sądzę by miało dla niego jakąś różnicę czy będzie leciał po liście, wpis po wpisie, czy będzie wklepywał ID w GET.

Natomiast jeśli chodzi Ci o to, że admini mają różny dostęp do zasobów to w pliku usuwającym, który otrzymuje dane za pomocą GET sprawdź najpierw czy dana osoba ma uprawnienia do usunięcia danego rekordu.

[viking]

Jak ktoś otrzyma dostęp, to co za różnica jaka metoda została użyta do usuwania? POST czy GET? I tak ma dostęp do całej listy.

A słyszał waść o takim sprytnym ataku co to jesteś zalogowany jako admin, odwiedzasz stronę i klikasz na spreparowany link http://x/delete.php?id=1 ? Dlatego właśnie zawsze takie dane usuwa się POSTem.

Może użyj Ajaxa? Wtedy kasowanie będzie się odbywało bez przekierowania na kolejną podstronę. Tak czy siak, jak ktoś się włamie, to nie sądzę by miało dla niego jakąś różnicę czy będzie leciał po liście, wpis po wpisie, czy będzie wklepywał ID w GET.

Korzystając z XHR masz możliwość wstawiania dodatkowych nagłówków zabezpieczających. Teraz już ze względu na przeróżne nowinki w przeglądarkach mniej, ale kiedyś istniała polityka jednej domeny.

[Ulysess]

a POST jest zabezpieczeniem ..
1)mając pluginy do FF można wysłac na serwer jakie się chce dane postem -> Web Developer
2) curl
tak jak kolega 2 posty wcześniej napisał , wywołując skrypt sprawdzaj czy osoba go wywołująca ma uprawnienia.
spreparowany link ? hmm ok w takim razie osoba która Tobie go dostarczy musiała by znac budowę panelu admina
nie popadajmy w paranoje..

[markonix]

@up
Nie no akurat plugin to by musiałby być zainstalowany u atakowanego, a nie atakującego.

Jak już to zagrożeniem jest po prostu ukryty formularz, na którym robimy submit() gdy ofiara wejdzie i to cała filozofia, atak na poziomie gimnazjum, a jakże skuteczny

[Ulysess]

hmm a np dodatkowe Pole w bazie w którym znajdował by się unikalny ciąg znaków np:
mamy delete.php?hash=fsdfasdfaosid
skrypt sprawdza czy w bazie istnieje taki hash , jesli tak to kasowany jest post z tym hashem ? co sądzicie ?..

[viking]

a POST jest zabezpieczeniem ..

Nie zrozumiałeś zupełnie. Sam wykonujesz akcję a nie atakujący zmienia parametry w narzędziach. Tu nie chodzi o żadną paranoję a podstawy. Takie rzeczy mają być z automatu zabezpieczane. Bo np jakiś dobry kolega z którym akurat się pokłóciłeś podeśle taką świnię a ty oczywiście nie robisz backupów, i co?

Więcej jest też opisane na portalu http://php.pl/Wortal/Artykuly/Bezpieczenst...wa-skryptow-PHP

[Tuminure]

POST jest tak samo bezpieczny, jak GET.
Przesłanie spreparowanego ciągu znaków POSTem wymaga zaledwie ciut większej wiedzy (w gruncie rzeczy trzeba tylko wiedzieć, że takie coś jest możliwe, a potem wpaść na pomysł jak lub po prostu wygoglować) i ciut większego wysiłku.

Nie rozumiem po co chcesz to zabezpieczyć. Jeżeli ktoś ma dostęp do panelu administracyjnego i może usunąć artykuł za pomocą POSTa/GETa, to równie dobrze może usunąć go z poziomu tabeli, którą wyświetlasz (i która usuwa przez POST/GET. Jeżeli ktoś nie ma dostępu do tabeli, to nie powinien mieć też dostępu do strony "/delete.php" (a co za tym idzie "/delete.php?id=1" nie zadziała lub wyświetli stronę logowania).

A powiedzmy, gdybyśmy nie chcieli chronić się już przed nami samymi tylko przed innymi użytkownikami którzy także korzystają z portalu (bo taka była moja ogólna intencja)?
Jak najlepiej zabezpieczyć się przed hax0rami ;] którzy wszedzie wtykają swoje klawiaturki?

[PHP] pobierz, plaintext 
if($user->role == 'admin')
{
    if(isset($_POST['comment_id']))
    {
        echo 'usuwam komentarz ' . $_POST['comment_id'];
    }
    else
    {
        echo 'podaj id komentarza';
    }
}
else
{
    echo 'nie masz dostepu';
}
[PHP] pobierz, plaintext 

Można równie dobrze wykorzystać $_GET, jednak skłoniłbym się do tego, by GET służył do pobierania czegoś ze strony, a POST do wysyłania czegoś na stronę.

Ten post edytował Tuminure 18.09.2012, 07:33:34

[CuteOne]

UP: i Twoja filozofia upada gdy zamiast POST'em dane wysyłane są GET'em

[PHP] pobierz, plaintext 
if($user->role == 'admin')
{
    if(isset($_GET['comment_id']))
    {
        echo 'usuwam komentarz ' . $_GET['comment_id'];
    }
    else
    {
        echo 'podaj id komentarza';
    }
}
else
{
    echo 'nie masz dostepu';
}
[PHP] pobierz, plaintext 

http:// www.strona .pl/panel_admina/index.php?action=delete&id_comment=12
podmieniasz na spreparowany link
http://www.kasa_za_darmo.pl/?a=12
lub fajniejszy
Skrypt zarabiający za darmo

wysyłasz na gg/skype/mail lub forum ofiary i ta naiwna osoba sama kasuje sobie komentarz - gorzej gdy zamiast komentarza skasuje sobie konto. Dlatego zawsze ale to zawsze akcje CRUD powinny być wykonywane za pomocą formularza.


ps. nie wiem nad czym się tak rozwodzicie - ACL + to co wyżej napisałem i po sprawie

Ten post edytował CuteOne 18.09.2012, 07:51:47

[wNogachSpisz]

Każdy user ma kolumnę user_level, od 1 do 5:
1. super admin
2. admin
3. moderator
4. zarejestrowany user
5. gość

Każdy post ma kolumnę author_id, więc post może zostać usunięty tylko przez autora lub przez usera o user_level 1 (superadmin) lub przez admina lub moderatora - w zależności jak skonfigurujesz sobie uprawnienia. Tak to jest zrobione w praktycznie każdym szanującym się softcie.

Metoda POST jest o tyle dobra, że przeglądarka nie będzie cachować zapytań POST, nie zostaną one zapisane w logach serwera www czy zacachowanie przez serwer proxy, także używanie POST do takich operacji jest jedynym wyjściem, upieranie się przy GET obnaża brak profesjonalizmu.

Kolejna sprawa to zabezpieczenia przez CSRF, jeśli rozumiesz jak działa atak CSRF, bez problemu wprowadzisz stosowane zabezpieczenia.
https://www.owasp.org/index.php/Cross-Site_..._Forgery_(CSRF)


P.S
A tak na marginesie, to rekordów z bazy się nie usuwa, tylko zmienia status
Powody są dwa: 1. Jeśli zechcesz odzyskać to co usunąłeś, to leżysz, bo rekordu nie ma 2. Jeśli któregoś dnia zechcesz sporządzić statystykę, np. ile postów napisano w danym okresie czasu, a ile usunięto, to leżysz bo usunąłeś rekord i informacja została utracona.

Ten post edytował wNogachSpisz 18.09.2012, 13:15:49