rest security

Wst¦pAutentykacja i sesja

AutoryzacjaWalidacja danych wej±ciowych

Kodowanie danych wyj±ciowychKryptogra�a

Bezpiecze«stwo REST API

Krzysztof Pobo»an

WPC Toru«,Agora S.A.

Toru«,16 marca 2015

Krzysztof Pobo»an Bezpiecze«stwo REST API




Agenda

1 Wst¦p

2 Autentykacja i sesja

3 Autoryzacja

4 Walidacja danych wej±ciowych

5 Kodowanie danych wyj±ciowych

6 Kryptogra�a





Wst¦p

REST (REpresentational State Transfer) - uwidocznienie encji za pomoc¡elementów URL. REST nie jest architektur¡, a stylem architektonicznympozwalaj¡cym budowa¢ usªugi na bazie Web. REST preferuje interakcjebazuj¡cym na elementach Web poprzez proste URLe ponad skomplikowanezapytania.





Autentykacja i sesja

Usªugi RESTful powinny u»ywa¢ autentykacji bazuj¡cej na sesji z tokenem lubwykorzystuj¡c klucz API. Nazwa u»ytkownika, hasªo, token lub klucz API nigdynie powinien by¢ przekazywany w URL.Mo»na u»y¢ TLS albo OAuth i SSL.





Ochrona sesji

Serwis z zaªo»enia jest bezstanowy. W zwi¡zku z tym:Sesja klienta powinna by¢ identy�kowalna przez tokena albo klucz API wcashu serwera."Anti-replay" - zabezpieczenie przed skopiowaniem cz¦±ci requesta do innegoprzez atakuj¡cego w celu podszycia si¦. Klucz szyfruj¡cy powinien by¢ograniczony czasowo i by¢ zwi¡zany z: tokenem lub kluczem API, dat¡generowania i ip sk¡d przyszªo »¡danie.

W skrócie nie dopuszcza¢ do u»ywania adresu w stylu:

https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false





Anty-farmienie





Ochrona metod HTTP

Upewni¢ si¦ »e dany u»ytkownik mo»e wykona¢ dan¡ metod¦.





Ochrona





Biaªa lista czasowników

Dost¦pno±¢ metod powinna by¢ na zasadzie biaªej listy.Odpowiedni kod bª¦du (np. 403 Brak uprawnie«)!





Uprzywilejowane akcje i czuªe dane

Nale»y pilnowa¢ by zawsze przesyªa¢ token lub klucz API w celu wery�kacjiuprawnie« (je±li nie u»ywamy Basic Authenticate).





Zapytania mi¡dzydomenowe (CSRF)

Metody PUT, POST i DELETE musz¡ by¢ zabezpieczone przeciwko atakowiCSRF np. poprzez u»ywanie losowych tokenów.





Walidacja danych wej±ciowych

Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkienarusznie reguª walidacji.Bezpieczne parsowanie, Upewnienie si¦ »e przy np. wej±ciu w formacie XMLbiblioteka parsuj¡ca jest odporna na ataki typu XXESilne typowanie. W ramach typowaia sprawdzamy nie tylko typ ale i wielko±¢danych.nie ufamy polu Content-Type w nagªówku dla metod POST i PUT. Je±liCOntent-Type nie zgadza si¦ z rzeczywist¡ zawarto±ci¡ nale»y zwróci¢: 406Not Acceptable. �ci±le kontrolowa¢ dost¦pne formaty danych wej±ciowych.Najlepiej przed deserializacj¡.Walidujemy typ wyj±ciowy.


https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing





Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkienarusznie reguª walidacji.

Bezpieczne parsowanie, Upewnienie si¦ »e przy np. wej±ciu w formacie XMLbiblioteka parsuj¡ca jest odporna na ataki typu XXESilne typowanie. W ramach typowaia sprawdzamy nie tylko typ ale i wielko±¢danych.nie ufamy polu Content-Type w nagªówku dla metod POST i PUT. Je±liCOntent-Type nie zgadza si¦ z rzeczywist¡ zawarto±ci¡ nale»y zwróci¢: 406Not Acceptable. �ci±le kontrolowa¢ dost¦pne formaty danych wej±ciowych.Najlepiej przed deserializacj¡.Walidujemy typ wyj±ciowy.







Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkienarusznie reguª walidacji.Bezpieczne parsowanie, Upewnienie si¦ »e przy np. wej±ciu w formacie XMLbiblioteka parsuj¡ca jest odporna na ataki typu XXE

Silne typowanie. W ramach typowaia sprawdzamy nie tylko typ ale i wielko±¢danych.nie ufamy polu Content-Type w nagªówku dla metod POST i PUT. Je±liCOntent-Type nie zgadza si¦ z rzeczywist¡ zawarto±ci¡ nale»y zwróci¢: 406Not Acceptable. �ci±le kontrolowa¢ dost¦pne formaty danych wej±ciowych.Najlepiej przed deserializacj¡.Walidujemy typ wyj±ciowy.







Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkienarusznie reguª walidacji.Bezpieczne parsowanie, Upewnienie si¦ »e przy np. wej±ciu w formacie XMLbiblioteka parsuj¡ca jest odporna na ataki typu XXESilne typowanie. W ramach typowaia sprawdzamy nie tylko typ ale i wielko±¢danych.

nie ufamy polu Content-Type w nagªówku dla metod POST i PUT. Je±liCOntent-Type nie zgadza si¦ z rzeczywist¡ zawarto±ci¡ nale»y zwróci¢: 406Not Acceptable. �ci±le kontrolowa¢ dost¦pne formaty danych wej±ciowych.Najlepiej przed deserializacj¡.Walidujemy typ wyj±ciowy.







Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkienarusznie reguª walidacji.Bezpieczne parsowanie, Upewnienie si¦ »e przy np. wej±ciu w formacie XMLbiblioteka parsuj¡ca jest odporna na ataki typu XXESilne typowanie. W ramach typowaia sprawdzamy nie tylko typ ale i wielko±¢danych.nie ufamy polu Content-Type w nagªówku dla metod POST i PUT. Je±liCOntent-Type nie zgadza si¦ z rzeczywist¡ zawarto±ci¡ nale»y zwróci¢: 406Not Acceptable. �ci±le kontrolowa¢ dost¦pne formaty danych wej±ciowych.Najlepiej przed deserializacj¡.Walidujemy typ wyj±ciowy.






Zawsze wysyªamy

Powinno si¦ wysyªa¢: X-Content-Type-Options: nosniff aby mie¢pewno±¢, »e klient nie b¦dzie próbowaª rozpozna¢ rodzaju tre±ci pozawarto±ci.

JSON - zarawrto±¢ elementów DOM nigdy nie powinny by¢ mody�kowanepoprzez .innerHtml a za pomoc¡ .value/.innerText/.textContent aby chroni¢si¦ przed prostymi atakami DOM XSS

XML - nigdy nie powinnien by¢ budowany poprzez sklejanie stringa, apoprzez serializacj¦. To zapewnia »e XML jest parsowalny dla przegl¡darek inie zawiera wstrzykni¦¢.





Je±li caªo±¢ udost¦pniana przez serwis nie jest tylko do odczytu to obowi¡zkowopowinno si¦ u»ywa¢ TLS.Dla szczególnie wra»liwych danych powinni±my u»ywa¢ uwie»ytelniania klientacerty�katem.

Andrew van der Stock Erlend Oftedal.Rest security cheat sheet.https://www.owasp.org/index.php/REST_Security_Cheat_Sheet.

Bhakti Mehta.RESTful Java Patterns and Best Practices.Packt Publishing Ltd., 2014.


https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

rest security

Internet