Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Ajax jak zabezpieczyć ?
Forum PHP.pl > Forum > XML, AJAX > AJAX
Qss
Witam,

Zrobiłem pewna aplikacje gdzie dodawanie edycja i usuwanie oparte jest o ajax a później uświadomiłem sobie że to co zrobiłem jest to ekstremalnie niebezpieczne

Przykład bazy:

Tabela user
userID | nick | haslo

Tabela cos1
cos1ID | userID (FK) | jakiespole

Tabela cos2
cos2ID | cos1ID (FK) | jakiespole


Teraz funcja javasctipt
  1. function usun(id){
  2. // i tu przez ajaxa usuwa dane z tabeli cos2ID o zadanym id
  3. // i zapytanie po stronie php w stylu
  4. // DELETE FROM cos2 WHERE cos2ID = $_POST['id']
  5. }


Jeśli ktoś to zobaczy w podgladzie strony to z konsoli może wywołać funkcje i jako parametr podać dowolne ID które nawet nie należy do niego i usunąć komukolwiek pewne dane

To co wymyśliłem to przed usunięciem (oczywiście po stronie PHP) sprawdzić czy zadane id (poprzez tabele cos1) należy do userID zalogowanego użytkownika ale to tylko dodatkowe zapytania i obciążenie bazy
lub do tabeli cos2 dodac tez FK do usera co sprowadzało by się tylko do dopisania w zapytaniu WHERE userID = $_SESSION['idZalogowanego']

Tabela cos2
cos2ID | cos1ID (FK) | jakiespole | userID (FK)

Jakieś inne pomysły aby zachować strukturę bazy ? Bo przy takim rozwiązaniu baza traci trochę na spójności
karakara
Cytat(Qss @ 3.01.2013, 22:49:10 ) *
dopisania w zapytaniu WHERE userID = $_SESSION['idZalogowanego']


No i tak będzie dobrze.

Qss
Poradziałem sobie i wymyśliłem coś takiego nie naruszając bazy danych
  1. DELETE FROM cos2 WHERE cos2ID = $_POST['id'] AND cos1ID IN (SELECT cos1ID FROM cos1 WHERE userID = $_SESSION['idzalogowanego']) LIMIT 1
markonix
Ajaxa zabezpiecza się tak samo jak zwykłe odwołania.

Np. nie ma znaczenia czy usuwasz dany wpis poprzez link:
?delete=10 (GET)
, przycisk
<button delete="10">Usuń</usuń> (AJAX)
czy POST.

We wszystkich przypadkach użytkownik może spreparować ID, czasem łatwiej (przy metodzie GET), czasem troszkę trudniej bo trzeba włączyć firebuga (POST, AJAX).
Jeżeli chcesz informować o braku autoryzacji to sprawdzasz to na początku, a jeżeli nie to możesz oprócz id przy usuwaniu dodać drugi warunek czy zalogowany jest równy autorowi/właścicielowi obiektu (nie rozumiem po co tu subquery).
Qss
Cytat(markonix @ 4.01.2013, 16:19:55 ) *
oprócz id przy usuwaniu dodać drugi warunek czy zalogowany jest równy autorowi/właścicielowi obiektu (nie rozumiem po co tu subquery).


Właśnie to jest ten drugi warunek przynależności. Zauważ że w mojej bazowej wersji BD w tabeli z której chce usunąć nie ma informacji o właścicielu jest ona dopiero w tabeli nadrzędnej A nie chcąc zaburzać struktury bazy wsadzając wszędzie FK o userze lub nie tworzyć 2 zapytań (sprawdzającego i usuwania) zrobiłem subquery

Co do zabezpieczenia ajaxa to w sumie się zgodzę że robi sie to tak samo jak przy zwykłym przeładowaniu strony, aczkolwiek tu bardziej chodziło o to że w bazie niema o tym bezpośredniej informacji

Zapewne jeśli chodzi o szybkość zapytań było by lepiej to zrobić faktycznie FK.
markonix
No jeżeli obiekt ma kilka właścicieli to wtedy taka relacja ma sens, jeżeli zawsze jednego np. konto, temat, komentarz itp. to nie.
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.