Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [MySQL][PHP]Metoda na usunięcie rekordu z bazy
Forum PHP.pl > Forum > Przedszkole
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? wink.gif

Pozdrawiam.
Ulysess
co do 1 zabezpieczenia , rozumiem że chcesz się chronić przed sobą samym ?smile.gif skoro masz panel administracyjny to do tego panelu masz tylko Ty bądz zaufane Tobie osoby dostęp wiec w czym problem questionmark.gif
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:
  1. foreach ($_POST['id_message'] as $id_msn)
  2. {
  3. // tutaj akcja kasowania posta
  4. }
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?
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
Cytat(b4rt3kk @ 17.09.2012, 21:38:16 ) *
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.

Cytat
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 questionmark.gif..
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 wink.gif
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 smile.gif
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 ?.. biggrin.gif
viking
Cytat(Ulysess @ 17.09.2012, 22:06:33 ) *
a POST jest zabezpieczeniem questionmark.gif..

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).

Cytat
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?

  1. if($user->role == 'admin')
  2. {
  3. if(isset($_POST['comment_id']))
  4. {
  5. echo 'usuwam komentarz ' . $_POST['comment_id'];
  6. }
  7. else
  8. {
  9. echo 'podaj id komentarza';
  10. }
  11. }
  12. else
  13. {
  14. echo 'nie masz dostepu';
  15. }

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ę.
CuteOne
UP: i Twoja filozofia upada gdy zamiast POST'em dane wysyłane są GET'em smile.gif

  1. if($user->role == 'admin')
  2. {
  3. if(isset($_GET['comment_id']))
  4. {
  5. echo 'usuwam komentarz ' . $_GET['comment_id'];
  6. }
  7. else
  8. {
  9. echo 'podaj id komentarza';
  10. }
  11. }
  12. else
  13. {
  14. echo 'nie masz dostepu';
  15. }

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
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 tongue.gif
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.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.