Introduction to Web Security
Download as PPTX, PDF0 likes678 views
Web security involves authentication, which verifies a user's identity, and authorization, which determines what resources a user can access. Traditionally, session-based authentication stored data on the server-side, but modern stateless authentication uses tokens passed in requests. Cookies and tokens maintain state at the client-side in a stateless manner. Libraries can help with authorization rules, roles, and multi-factor authentication.
Introduction to Web Security
- 1. Web Security • What is security in web app context? • Authentication vs Authorization • „Standard” way - Stateful • „Modern” way - Stateless • Cookies and Tokens • Double and 2-step verification • Useful libraries • Summary
- 2. What is Security? • practice of defending information from unauthorized access • keeping away all valuable information from unprivileged users • protecting data from leaking outside the company • storing confidential informations only for provisioned roles
- 5. Session • Storing data on server side • Client passes back only id • Server knows what user it is talking to • Lasts form first user's visit on the page and is kept some time after his last activity (request) • It almost impossible to know that user left the page • In most servers session express after particular period
- 6. RESTful • The whole state need to be held by the client, not the server • State is being transfered in every request to release server from remembering it • An ideal RESTful service allows clients to perform any needed task in one request Stateless? Actually, there is a state! thentication, some information has to stay on the server side
- 7. And what about cookies? • If cookies are used to maintain state at the client side, for the client, of the client and by the client then they are restful. • For clients besides browsers, managing cookies is a pretty big inconvenience compared to query params • However in browser, using cookies can make lots of things much simpler • API should first look in the Authorization header for the authentication data (the place for non-browser clients) and in case authentication data is missing then may also check for a session cookie • When we are the only developers who creating apps which can access to our web service, we can depend on cookies and implement cookie mechanisms in our applications
- 8. Login Token Request Response Data DB Use the new TLS! • Asymmetric cryptography • Secure data between connection endpoints • Client encrypts data, Server decrypts it • Protects from MITM
- 9. Multi-factor authentication Token + • IP • User Agent • SMS • Biometric • Face • Electronic signature • Codes from card
- 14. Useful GEMs for Rails • the_role | https://github.com/the-teacher/the_role Which resources are available for what role (group of users) Roles and permissions are declared with JSON and stored in DB Access can be managed from administrative panel within our web app • declarative_authorization | https://github.com/stffn/declarative_authorization The developer needs to specify which roles are allowed to access a specific controller action or a part of a view Authorization at controller, model or view level DSL for specifying Authorization rules • devise | https://github.com/plataformatec/devise Complete MVC solution based on modularity concept Offers complete session model for authentication Provide generators for scaffolding authorization skeleton
- 15. $ npm install jsonwebtoken $ bower install jsjws http://jwt.io/#
Editor's Notes
- #2: W tej prezentacji chciałbym przedstawić podstawowe zagadnienia w temacie bezpieczeństwa w aplikacjach typu Single Page. Opowiem między innymi o: bezpieczeństwie samym w sobie jak możemy chronić nasze serwisy przedstawię różne podejścia do tematu bezpieczeństwa i sposoby weryfikacji użytkownika a na koniec wskażę pomocne narzędzia w temacie zabezpieczeń In this presentation I'd like to cover a brief introduction to security topics in Single Page Applications. I will say about: Security in web app How can we protect our services Different approach to web security Ways of users verification Helpful tools
- #3: Żeby w ogóle zacząć mówić o szczegółach dotyczących bezpieczeństwa, na początek musimy sobie zdefiniować czym to bezpieczeństwo właściwie jest. Bo mówiąc ogólnie - bezpieczeństwem możemy nazwać zestaw akcji, które musimy podjąć by chronić nasze dane przed nieuprzywilejowanym dostępem przez niechciane osoby lub systemy. Czyli są to wymagane kroki, których wynikiem jest ochrona przed niepożądanym zachowaniem. > Chcemy tworzyć bezpieczne systemy w tym sensie, że nie tylko użytkownik będzie czuł, że jego dane są bezpiecznie, ale także, musimy rzeczywiście chronić je przed złośliwymi operacjami czy nawet atakami. To start talking about security details, firstly we need to define what actually the security is. Talking in general - security is a set of actions which taking protect our data and prevent them from access by unwanted users or systems. So it’s a bunch of steps required for defending us from unauthorized actions. We want to keep our systems secure to give users not only feeling that their data is safe but really prevent it from any malicious operations and attacks.
- #4: Bardzo istotną kwestią jest rozróżnienie tych dwóch pojęć: Authentication i Authorization. Co ciekawe, w języku polskim, tylko jedno z nich jest tłumaczone prawie bezpośrednio. Authorization to oczywiście autoryzacja, natomiast Authenticiation to już uwierzytelnianie. Nie ma takiego słowa jak autentykacja, czy nawet autentyfikacja. Jeżeli popełnię taki błąd to krzyczcie od razu. Jedno z tych pojęć oznacza tyle co sprawdzenie tego, kto chciałby uzyskać dostęp do naszego serwisu, podczas gdy drugie to sprawdzenie czy znany nam użytkownik może poprosić o te, konkretne zasoby. At the beginning we need to distinguish between Authentication and Authorization which are often misunderstood. What is interesting, authentication is usually translated incorrectly in polish. It's "uwierzytelnianie", not "autentykacja". One of them is to define wether web service knows who the user is and the other one allows user to access some particular information.
- #5: I teraz lekki mindfuck. Kod 401, używany przy uwierzytelnianiu, czyli jak pamiętacie Authentication, niesie za sobą wiadomość Unauthorized. W tym przypadku, powinniśmy zawsze dołączać nagłówek HTTTP WWW-Authenticate, który wskazuje możliwy sposób uwierzytelnienia. Jeżeli jednak zapytanie zawierało dane uwierzytelnienia takie jak login i hasło, ten kod oznacza podanie błędnego hasło dla danego użytkownika. Kod 403, używany przy autoryzacji, czyli jak pamiętacie Authorization, niesie za sobą wiadomość Forbidden. Serwer rozumie zapytanie i zna użytkownika, natomiast odmawia mu dostępu do zasobów. > Czyli podsumowując: 401 - brak lub złe dane użytkownika, 403 - brak wystarczających uprawnień. 401 Unauthorized (for authentication errors): It will always include a WWW-Authenticate header that describes how to authenticate. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. 403 Forbidden (for authorization problems): The server understood the request, but is refusing to fulfill it. In summary, a 401 Unauthorized response should be used for missing or bad authentication, and a 403 Forbidden response should be used afterwards, when the user is authenticated but isn’t authorized to perform the requested operation on the given resource.
- #6: HTTP jest protokołem bezstanowym, tzn. że nie możemy powiązać .ze sobą kolejnych zapytań. Musi więc istnieć sposób na przechowywanie stanu pomiędzy tymi zapytaniami. Klienci wysyłają dane do serwera takie jak metoda, atrybuty, ciasteczka, przeglądarka czy źródło pochodzenia. > HTTP is a stateless protocol. You can’t associate a one request to another. There need to be some way to keep state. Browser sends some data to server like method type, request attributes, cookies, user agent and refereer.
- #7: REST jest skrótem od Representational State Transfer. > Jest ściśle powiązany z bezstanowością, jednak tylko na serwerze. > Istnieje potrzeba pamiętania klienta, który wykonuje dane zapytania. > REST is an abbreviation of Representational State Transfer. It strictly connected with the stateless but only on the server side. There is a need to remember what clients are authenticated
- #8: Ciasteczka są niczym innym jak nagłówkami HTTP. Jaka jest więc różnica czy przekażemy dane w nagłówku Authorization lub Cookie? Ciasteczka mogą być ograniczone czasowo, tj. mieć datę ważności. Mogą też być zaszyfrowane, są wygodne w użyciu. Komunikacja pomiędzy klientem a serwerem RESTowym jest bezstanowa w tym sensie, że dane pomiędzy kolejnymi zapytaniami i w ramach różnych sesji nie zwiększają się. Cookies are simply HTTP header. What is the difference if we pass some data in Authorization or in Cookie header? Cookies can be time-limited. Cookies can be encrypted. Cookies are safe and convenient. The communication between the REST service and the REST client is stateless, when the data stored by the service does not grow with the count of the user sessions.
- #9: TLS - Transport Layer Security (1.2) - by protocol > („handshake”) SSL - Secure Socet Layer (3.0) - by port :443 (secure by default) TLS is cryptographic protocol which is designed to provide communication security over the Internet Part of lower sublayer of application layer in OSI model > Work on behalf of the underlying transport layer, whose segments carry encrypted data
- #10: - Binding token to IP my cause user of mobile internet (like LTE) need to reauthenticating all the time for example during train travel - User Agent is just specific string, very specific at the first sight but easy to forge - We need to provide something what potentially hacker cannot steal
- #11: Method of attack that fakes websites which requires authentication. Cookies themselves are not the cause of CSRF vulnerabilities. It’s using the cookies on the server to validate a user that is the cause of CSRF. When a Single Page App loads it can read the cookies (via JavaScript), grab the authentication token, and then manually send that token on each request through a custom HTTP header.
- #12: Embedding JS scripts on websites. Same origin policy allows to use objects that comes only from the same source as website URL (protocol, host, port). Javascript injection - sanitazing input
- #13: Create separate app-specific password and then provision with an additional SMS code. Returns token which gain access to application. Twitter was hacked by fake email.
- #14: oAuth - the way to provision users in third-party services to get access to your own service An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. A simple way to publish and interact with protected data. Have access to users data while prodecting their credentials.
- #15: Role: Lightweight library for defining roles for users Roles are connected with controller actions Administrator role with full access Declarative: From the one side User is assigned to Role From the second side Developer specifies which permissions are required for user to perform activities (call controller, perform DB operation, display view fragments) Permissions have a bunch of Privileges and Context (perm - uprawnienie, privi - przywilej) In configuration Permissions are assigned to Roles Devise: The heaviest and the biggest authentication library for Rails Provide comprehensive security rules for web application Supports asynchronous requests, oAuth, multi-step verification, timeouts, validations, black lists and many well-known features