Posts

Showing posts from 2018

DOUBLE SUBMIT COOKIE PATTERN

Image
This is also a common method to mitigate (CSRF) attacks. Let's see how it works. In SYNCHRONIZER token pattern method csrf token can be stored in the session. but for a large number of users, it may cause to be a problem so DOUBLE SUBMIT COOKIE PATTERN is can be considered an alternative solution for this problem. In this case, csrf token is not stored in the server side. It will be sent to the client via a cookie. When the client making a request from the server, the client fetches the token and send to the server for validation. Let's make this clear using below diagram. Let's get clear these steps one by one using this sample Application. (In bellow screens this application runs on localhost and enables SSL and Virtual host test for port 443 you can use any configuration as you prefer (enable SSL is recommended)). Step 1:- User make get a request to test.com the server returns the login page to th...

OAUTH 2

Image
OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and DigitalOcean. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices. This informational guide is geared towards application developers and provides an overview of OAuth 2 roles, authorization grant types, use cases, and flows. Let's get started with OAuth Roles! OAuth Roles OAuth defines four roles: Resource Owner Client Resource Server Authorization Server We will detail each role in the following subsections. Resource Owner:  User The resource owner is the  user  who authorizes an  application  to access their account. The application's access to the user's account is limited to the "scope" of t...

SYNCHRONIZER TOKEN PATTERN

Image
SYNCHRONIZER TOKEN PATTERN is a common method to mitigate  (CSRF)  attacks. Let's see how it works. In this method csrf token stores in the session. It will be extracted by ajax call and embedded to the client web page the client. When the client making a request from the server, the token also send to the server for validation. Let's make this clear using below diagram. Let's get clear these steps one by one using this sample Application. (In bellow screens this application runs on localhost and enables SSL and Virtual host test for port 443 you can use any configuration as you prefer (enable SSL is recommended)). step 1: User make get a request to test.com the server returns the login page to the user to enter credentials. then the user enters his credentials (user: pass) and press login. (Post request with credentials sends to the server.) Step 2 and 3 Now the user will be validated...

CROSS-SITE REQUEST FORGERY.

Image
                 Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application. So this is how the    www.owasp.org   describe    Cross-Site Request Forgery (CSRF). Let's try to understand CSRF by simple rea...