I have a Web API application and have configured SSL for it.
Our authentication mechanism is via the header. Each request will have to contain a pair of keys that we will validate them against our database. We're not using Forms/Basic or Digect authentication.
I'm just wondering do we have to do anything with regard to the Cross-Site Request Forgery (CSRF) issue? is it applicable in this case?
I thought because we're not using the cookies so it should be safe.
Indeed, forcing another user to do a request only has an advantage for an attacker if that user's browser automatically pushes some credential that the attacker does not have. That can be:
auth cookie
HTTP Authentication (Basic/Digest/Windows Auth)
TLS session ID (in HTTPS)
implicit authorisation from IP address or network location (eg intranet site)
If you are not relying on any such credential, then there is no CSRF attack to defend against.
Related
I'm learning about Basic Authentication and Jwt Authentication with Java and Spring and I want to ask you if basic authentication is a session based authentication?
I know that in a session based authentication, when the client log in, a sessionId is stored in cookie on the client browser and after that when the client make another request, the server compares the sessionId with the data stored in the memory of the server. And also I want to ask you how is the sessionId sent from client browser to server? Is it sent in the header like a token or how?
And the last question is how the server validate the Jwt token? I know that in case of session authentication, the sessionId sent from client is compared with the data from the memory of the server. But what's happen in case of Jwt authentication? The token is sent with the header and I know that the server validate it and there is no data in the memory of the server. Then how the server compares the token? Any feedback will be apreciated! Thank you!
if basic authentication is a session based authentication?
I know that in a session based authentication
well then why do you ask?
Actually - basic authentication means, that the user credentials(username and password) are sent in the Authorization http header
Authorization: Basic base64(username:password)
The server may or may not use a session cookie. Session cookie may be used with other authentication means or even without any authentication
how is the sessionId sent from client browser to server?
As a session cookie A session cookie is sent as an http header which browser treats as session-persistent
And the last question is how the server validate the Jwt token?
The JWT token should be signed. Note the token has usually 3 parts
header.body.signature
the header specifies a signature type (an asymmetric key or shared secret) and the signature is authenticated (signed or hmac-ed) header and content.
So - the server must validate the issuer, expiration and the signature.
So the server (service provider) doesn't need know the client's identity upfront. The service provider needs to know the issuer's (authentication service which issues the jwt token) public key or shared secret key.
After the jwt validation the service can assume the caller's identity based on the information in the jwt token.
why Jwt is more recommended?
It depends in the use case. (everything has its pros and cons)
I'd recommend using jwt in a distributed and/or microservice architecture. The service doesn't need to access the credentials or to authenticate the user.
In the basic authentication we need to send the username and password for every request.
In the session authentication we will send username and password at initial request. Then from server response we get the session id which stores in browser and gonna use that for requests.
In the token authentication we will send username and password at initial request. Then from server response we get the token and gonna use that for requests.
hope u got it!!
I'm a little confused about the cookie and I want to know can we use cookies somewhere other than the browser, like a mobile app or desktop app. Is the cookie dependent on the browser?
No, cookie is not dependent on browser.
Cookie is dependent on HTTP "User-Agent" -- the software/library client that is acting on behalf of a user, following HTTP protocol. Browser is just one type of it. Other types of "User-Agent" includes:
CLI software that can send HTTP request, such as curl or wget.
Library that can be imported in project and send HTTP request. Take Node.js project for example, they can be request or axios. All major programming language have its own HTTP client libraries.
Self-implemented HTTP client logic code.
more...
In a mobile app or desktop app, if HTTP is used for application, it is highly likely that cookie is used.
Any HTTP client can use cookies. A cookie is just a HTTP header sent by the server, with a value that is sent back to the server by the client in subsequent requests. Consult the documentation of your HTTP client to see if there is built-in support for remembering cookies.
Session Based Authentication
In the session based authentication, the server will create a session for the user after the user logs in. The session id is then stored on a cookie on the user’s browser. While the user stays logged in, the cookie would be sent along with every subsequent request. The server can then compare the session id stored on the cookie against the session information stored in the memory to verify user’s identity and sends response with the corresponding state!
Token Based Authentication
Many web applications use JSON Web Token (JWT) instead of sessions for authentication. In the token based application, the server creates JWT with a secret and sends the JWT to the client. The client stores the JWT (usually in local storage) and includes JWT in the header with every request. The server would then validate the JWT with every request from the client and sends response.
The biggest difference here is that the user’s state is not stored on the server, as the state is stored inside the token on the client side instead. Most of the modern web applications use JWT for authentication for reasons including scalability and mobile device authentication.
Scalability
Session based authentication: Because the sessions are stored in the server’s memory, scaling becomes an issue when there is a huge number of users using the system at once.
Token based authentication: There is no issue with scaling because token is stored on the client side.
Multiple Device
Session based authentication: Cookies normally work on a single domain or subdomains and they are normally disabled by browser if they work cross-domain (3rd party cookies). It poses issues when APIs are served from a different domain to mobile and web devices.
Token based authentication: There is no issue with cookies as the JWT is included in the request header.
Token Based Authentication: using JWT is the more recommended method in modern web apps. One drawback with JWT is that the size of JWT is much bigger comparing with the session id stored in cookie because JWT contains more user information. Care must be taken to ensure only the necessary information is included in JWT and sensitive information should be omitted to prevent XSS security attacks.
How can we prevent cross-site request forgery (CSRF) attacks in ASP.Net webForm. i want to secure some of pages in website and also how can we prevent if we received URL in the Email, from the attacker to perform CSRF.
You can take some extra precautions.
First connect your user authentication and actions, with the IP and the browser information's. So on each action, also verify that the actions are done from the user that have all that criteria.
encrypt some critical data/variables (that CSRF have to change) - and not let the variables only pass from SSL but plain text -
always use encrypted SSL cookies. requireSSL=true.
Do not allow cross app redirects enableCrossAppRedirects=false
Use one database table, to connect each authentication cookie with user actions like the log-out, so you know that the cookie is (maybe ?) logged out, or inactive, or something - even if its valid.
Block in advanced blocked ips that they have found that attacks.
http://www.phoenixlabs.org/pg2/
I am trying to learn JSON Web Tokens (JWT) and did a sample successfully using the article series present in Implement OAuth JSON Web Tokens Authentication in ASP.NET Web API and Identity 2.1 – Part 3.
I read about JWT and fond that the token can be decoded using JWT debugger present in https://jwt.io/ . The tokens are not encrypted – just encoded.
I have an existing ASP.Net web site which uses forms authentication. I am planning to make some functionality of this as Web API and use JWT for authentication.
Since JWT can be decoded, if some malicious hacker can read the token, they can get authenticated and get access to the resources.
Question 1
How is security of JWT compared to ASP.Net forms authentication? Is it more, less or equal secure over and unsecured network?
Question 2
The article "How to Avoid Session Hijacking in Web Applications"
illustrates a method for validating the IP address to which session_id was issued during login, and IP address of all subsequent requests, in the Application_AcquireRequestState event. This will be possible if the session id is stored in the server.
If I store the original IP addess on the JWT token also, is there a way to make sure that the token is not forged (to validate the original IP address and current IP address in each request)?
References:
Cookies vs Tokens. Getting auth right with Angular.JS
Session hijacking attack
What if JWT is stolen?
Stealing JWT from authenticated user
Content visibility of JWT is not a security issue because content is protected against alteration by a digital signature. But if an attacker gets access to a token, he can impersonate user. So use HTTPS if posible and keep the token in a secure storage
If you want to hide the content. JWT can be used with JWE encryption.
Forms authentication will probably use an opaque token in a cookie to maintain the server session. So if you store the JWT in a cookie marked with HTTPOnly I would say that security level is more or less the same. Note that cookies are vulnerable to CSRF attacks. However storing JWT in localStorage or accesible with javascript will do it vulnerable to XSS attacks.
In any case you need extra security measures, so there is no a magic solution and depends on the context
EDITED Question2 (Avoid session hijacking validating IP address
This technique can be applied in the same to JWT just adding the source IP address to the token. Since the token is signed, you can compare source TCP IP address with token address to validate the token origin.
Note that it is fully possible to send data with a fake sender IP, but replies will go to the fake IP address used by the sender, so they will never reach to the attacker.
But validating client IP has drawbacks, for example in mobile devices IP can change when the user switches from wifi to 4G, then the current token will be rejected
I am developing an API as a middleman between a Windows app and the database. The webserver will just be an ASP. NET generic handler returning json.
Users will log into the app and their credentials will be transmitted over the wire. From there what I was going to do was generate a session key that the app could use from then on with every request.
This will not be an open API in the foreseeable future.
Now what I am wondering is if this is secure enough? How can I stop people from using fiddler to just replicate the calls?
Is there a better approach to this? Would it help if I used SSL?
I don't want to complicate matters by using oauth.
Thanks!
Use SSL. In order to obtain the session token the client should authenticate himself with a username and password transmitted over SSL. Once authenticated the token should be transmitted to the server over SSL to prevent from man-in-the-middle attacks.
So here's the flow:
The client sends his credentials (username and password) over SSL to a web method
The web method verifies the credentials and generates a session token and returns this session token to the client.
The client sends the session token on subsequent requests to protected resources.
The server verifies the token and if valid grants access to the protected resource.
You use simple Forms Authentication to generate the session tokens. The FormsAuthentication.Encrypt and FormsAuthentication.Decrypt methods could be a good start for you. The forms authentication token contains an encrypted value of the currently authenticated user. If you are running in a web-farm make sure that you have static machine keys on all nodes of your web farm, otherwise a session token encrypted on one node might not be decrypted on another node.
As an alternative to session tokens you could use basic authentication over SSL. The drawback is that credentials are sent over the wire on each request. Even if you are using SSL, the password is still transmitted over the wire, so this method is less secure than session tokens but easier to setup.