Pokaż wyniki 1 do 7 z 7

Temat: json hacking

  1. #1
    Zarejestrowany
    Jan 2011
    Postów
    65

    Domyślnie json hacking

    testuje kod cmsa zbudowanego na php + json, co polecacie sprawdzac?

  2. #2
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    "if you don't know where to start, fuzz the sh*t out of it" -- anonymous

    JSON to tylko interfejs/API, podatnosci beda takie same jak w aplikacjach... poza tym jesli app uzywa JSON do komunikacji z backendem to mozesz rownie dobrze wlaic w aplikacje tymi samymi metodami co zawsze i patrzec kiedy padnie (zamiast szukac specjalizowanych narzedzi gadajacych JSON)...

    hint:
    tcpdump to Twoj przyjaciel :-) ja nagryma caly ruch gdy testuje cos - czasami mozna znalezc niezle kwiatki w ten sposob (np IPSy wysylajace RST jesli request zawiera odpowiedni string itd)
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  3. #3
    Zarejestrowany
    Nov 2009
    Postów
    643

    Domyślnie

    Sprawdź czy dane wysyłane w JSON są odpowiednio upakowane.
    używaj kolejnych kluczy numerycznych, wtedy ramka JSON jest najmniejsza..
    często lepiej dołożyć brakujący indeks i wrzucić w niego np. 0, niż stracić na narzucie spowodowanym koniecznością zapisania wszystkich indeksow w przypadku brakującego klucza psującego kolejność :P

    Sorry, ostatnio bawie się w optymalizowanie wszystkiego co się da, więc naszło mnie żeby napisać coś o JSONie skoro już ktoś pyta..

    Co to ma wspólnego z bezpieczeństwem? Nie wiem. Nie wiem czy JSON może mieć cokolwiek wspólnego z bezpieczeństwem, na pewno nie bezpośrednio.
    światło mądrości oświetla drogę z nikąd do nikąd

  4. #4
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Oj moze miec, moze...

    JSON jest najczesciej uzywany jako API... O ile ludzie uzywaja framework'ow do robienia stron i aplikacji, wiekszosc z tych framework'ow a dokladnie ich bibliotek nie dba o bezpieczenstwo backend'u a tylko o frontend (czyli to co pokazuje sie na WWW - HTML i okolice). Jesli masz JSON/SOAP/REST to koniecznie trzeba sprawdzic jak dziala ich obsluga - nie raz znajdziesz przypadek gdzie aplikacja webowa jest super, szybka, bezpieczna i w ogole... ale uzywa API do dostepu do danych i to API jest dziurawe jak ser szwajcarki. Wszystko zalezy od implementacji API - framework dziala wiec jak JS na stronach (wszyscy wiemy jak bardzo skuteczna jest filtracja wejscia robiona client-side, prawda?) :->

    To tak jak z fartuchami szpitalnymi - wydaje sie ze daja pelne pokrycie, do czas az sie nie odwrocisz (pokazesz API)

    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  5. #5
    Zarejestrowany
    Nov 2009
    Postów
    643

    Domyślnie

    JSON to tylko metoda enkapsulacji danych, stwierdzenie że aplikacja ma "błędy JSON" jest nieprawidłowe.
    Ja za błąd JSON mógłbym uznać np. błąd w funkcji parsującej...

    Chodzi bardziej o błędy w interfejsie obsługującym zapytania AJAX...
    Określanie ich mianem "błędów JSON" jest zbyt mocnym uproszczeniem.
    światło mądrości oświetla drogę z nikąd do nikąd

  6. #6
    Zarejestrowany
    Jan 2011
    Postów
    65

    Domyślnie

    dzięki za odpowiedzi. Wobec tego myślę, że ta książka Bezpieczestwo aplikacji tworzonych w technologii Ajax - Billy Hoffman, Bryan Sullivan - atrakcyjna cena, opis ksiki, recenzje i opinie - Wysylkowa.pl po doczytaniu więcej mi pomoże (jak źle myślę, to proszę o korektę)

    btw: TQM pięknie wyszedłeś na tym zdjęciu ;-)

  7. #7
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Hahaha :-)
    Ciesze sie ze Ci sie podoba ale to nie moje "API" ;-P
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

Zasady Postowania

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •  
Subskrybuj

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52