Secutity of REST

1. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Bezpiecze«stwo REST API
Krzysztof Pobo»an
WPC Toru«,Agora S.A.
Toru«,16 marca 2015

2. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Agenda
1 Wst¦p
2 Autentykacja i sesja
3 Autoryzacja
4 Walidacja danych wej±ciowych
5 Kodowanie danych wyj±ciowych
6 Kryptograa

3. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Wst¦p
REST (REpresentational State Transfer) - uwidocznienie encji za pomoc¡
elementów URL. REST nie jest architektur¡, a stylem architektonicznym
pozwalaj¡cym budowa¢ usªugi na bazie Web. REST preferuje interakcje
bazuj¡cym na elementach Web poprzez proste URLe ponad skomplikowane
zapytania.

4. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Autentykacja i sesja
Usªugi RESTful powinny u»ywa¢ autentykacji bazuj¡cej na sesji z tokenem lub
wykorzystuj¡c klucz API. Nazwa u»ytkownika, hasªo, token lub klucz API nigdy
nie powinien by¢ przekazywany w URL.
Mo»na u»y¢ TLS albo OAuth i SSL.

5. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Ochrona sesji
Serwis z zaªo»enia jest bezstanowy. W zwi¡zku z tym:
Sesja klienta powinna by¢ identykowalna przez tokena albo klucz API w
cashu serwera.
Anti-replay - zabezpieczenie przed skopiowaniem cz¦±ci requesta do innego
przez 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=falseallowCSRPanel=false

6. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Anty-farmienie

7. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Ochrona metod HTTP
Upewni¢ si¦ »e dany u»ytkownik mo»e wykona¢ dan¡ metod¦.

8. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Ochrona

9. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Biaªa lista czasowników
Dost¦pno±¢ metod powinna by¢ na zasadzie biaªej listy.
Odpowiedni kod bª¦du (np. 403 Brak uprawnie«)!

10. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Uprzywilejowane akcje i czuªe dane
Nale»y pilnowa¢ by zawsze przesyªa¢ token lub klucz API w celu werykacji
uprawnie« (je±li nie u»ywamy Basic Authenticate).

11. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Zapytania mi¡dzydomenowe (CSRF)
Metody PUT, POST i DELETE musz¡ by¢ zabezpieczone przeciwko atakowi
CSRF np. poprzez u»ywanie losowych tokenów.

12. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Walidacja danych wej±ciowych

13. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Walidacja danych wej±ciowych
Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkie
narusznie reguª walidacji.

14. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Walidacja danych wej±ciowych
Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkie
narusznie reguª walidacji.
Bezpieczne parsowanie, Upewnienie si¦ »e przy np. wej±ciu w formacie XML
biblioteka parsuj¡ca jest odporna na ataki typu XXE

15. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Walidacja danych wej±ciowych
Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkie
narusznie reguª walidacji.
Bezpieczne parsowanie, Upewnienie si¦ »e przy np. wej±ciu w formacie XML
biblioteka parsuj¡ca jest odporna na ataki typu XXE
Silne typowanie. W ramach typowaia sprawdzamy nie tylko typ ale i wielko±¢
danych.

16. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Walidacja danych wej±ciowych
Walidujemy 110% wi¦cej ni» jak obsªugujemy formularz. Logowa¢ wszystkie
narusznie reguª walidacji.
Bezpieczne parsowanie, Upewnienie si¦ »e przy np. wej±ciu w formacie XML
biblioteka 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±li
COntent-Type nie zgadza si¦ z rzeczywist¡ zawarto±ci¡ nale»y zwróci¢: 406
Not Acceptable. ‘ci±le kontrolowa¢ dost¦pne formaty danych wej±ciowych.
Najlepiej przed deserializacj¡.
Walidujemy typ wyj±ciowy.

17. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
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 po
zawarto±ci.

18. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
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 po
zawarto±ci.
JSON - zarawrto±¢ elementów DOM nigdy nie powinny by¢ modykowane
poprzez .innerHtml a za pomoc¡ .value/.innerText/.textContent aby chroni¢
si¦ przed prostymi atakami DOM XSS

19. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
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 po
zawarto±ci.
JSON - zarawrto±¢ elementów DOM nigdy nie powinny by¢ modykowane
poprzez .innerHtml a za pomoc¡ .value/.innerText/.textContent aby chroni¢
si¦ przed prostymi atakami DOM XSS
XML - nigdy nie powinnien by¢ budowany poprzez sklejanie stringa, a
poprzez serializacj¦. To zapewnia »e XML jest parsowalny dla przegl¡darek i
nie zawiera wstrzykni¦¢.

20. Wst¦p
Autentykacja i sesja
Autoryzacja
Walidacja danych wej±ciowych
Kodowanie danych wyj±ciowych
Kryptograa
Je±li caªo±¢ udost¦pniana przez serwis nie jest tylko do odczytu to obowi¡zkowo
powinno si¦ u»ywa¢ TLS.
Dla szczególnie wra»liwych danych powinni±my u»ywa¢ uwie»ytelniania klienta
certykatem.
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.