Ajax jak zabezpieczyć ? Opcje

[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

[PHP] pobierz, plaintext 
function usun(id){
 // i tu przez ajaxa usuwa dane z tabeli cos2ID o zadanym id
// i zapytanie po stronie php w stylu
// DELETE FROM cos2 WHERE cos2ID = $_POST['id']
}
[PHP] pobierz, plaintext 

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]

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

[SQL] pobierz, plaintext 
DELETE FROM cos2 WHERE cos2ID = $_POST['id'] AND cos1ID IN (SELECT cos1ID FROM cos1 WHERE userID = $_SESSION['idzalogowanego']) LIMIT 1
[SQL] pobierz, plaintext 

[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]

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.