I have a requirement of authoring a request first based on the passed Request Authorization Header and than providing the Servlet API response, now the servlet response will be cached on dispatcher, so need to enable Permission Sensitive Caching on my Dispatcher and need to create a Auth Checker Servlet which would be called by the Dispatcher before the dispatcher gives the Servlet Response from the Cache. Now, I wanted to know if the dispatcher, while making the HEAD call to the Auth Checker servlet, forward the Request Headers as well(which it receives in the client request) to the Auth Checker Servlet.
yes, all client headers will be passed to the Auth Checker Servlet including User-Agent, Host, Referer, Accept-* headers,. etc.
Related
I am learning about CSRF Tokens and how they help secure your web application. I understand the basics of it, but I am confused as to how it works in practice when the web server and api are separate. In practice how is the token generated, added to the HTML and known by the API?
For example, if I host my web app on something like Nginx or S3 and serve APIs via Spring Boot, how does the HTML with the embedded token get generated and passed to the client? Would the Sprint Boot API need to generate the token and HTML and return that to the client? Is there a different flow that am I missing? If this is the case, what is the point of it being embedded in HTML at all?
All of the documentation I have read assumes you are using something like MVC or skips over this entirely.
CSRF protection is only necessary for requests made by a client (for example, a browser) that silently adds credentials for the current user, by sending a session cookie, resending username and password that were previously typed in ("Basic Authentication") or by including a client certificate. This is because users may be tricked into making unwanted such requests by visiting a malicious web page, and these unwanted requests are then made with their credentials, that is, on their behalf.
For requests made by your web server to an API endpoint, this does not apply, therefore the API endpoint need not offer CSRF protection. A web server cannot be tricked into making unwanted requests.
Or can it? Imagine that the web server offers a "proxy" endpoint that converts incoming requests into requests to the API endpoint, and that sends the API response back to the client:
Client --request--> web server --converted request--> API endpoint
Client <--converted response-- web server <--response-- API endpoint
Further imagine that, as part of the request conversion, credentials from the client are forwarded to the API. For example, a session cookie coming from the browser is converted into an Authorization: Bearer <jwt> header that is sent to the API endpoint. Then an unwanted request to the web server endpoint with credentials effectively becomes a request to the API, and a new CSRF vulnerability has appeared: this time on the web server.
The web server must then protect its own "proxy" endpoint against CSRF by issuing and validating a CSRF token.
This project is on nuxtjs.
I don't think is important but maybe it can be some clue.
I need to get order detail information for using axios and below url.
/users/orders/d/20210806000349
but, very weird because axios doesn't request without cookies that url
of course i do set withCredentials: true already
when i change that url to /20210806000349 everyting is okay
someone help me about this?
I need more detail about domains but maybe api domain and nuxt domain are different. in this case you should care about CORS.
what is CORS
Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading of resources. CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.
MDN
what happen if you request to foreign domain?
user agent send an option request to foreign host
foreign host send response whit some header
user agent looks to Access-Control-Allow-Origin header and if its value is not equal to your domain block request
if request's withCredentials be true look at Access-Control-Allow-Credentials header and if its value be true send request with cookie. otherwise send request without cookie.
figure out myself
get request also preflight options request if domain is different
but in this case chrome doesn't show up options request
i check this on firefox
I'm trying to implement JWT authentication in a SvelteKit-app and I'm having trouble with where in the code I should refresh my accesstoken on site-reload.
According to what I have found I should store the JWT in memory and then have a refresh-token that is stored as a HTTP-only cookie. When the page is reloaded or opened in a new tab, I need to call my backend to see if the refresh-token is valid or not, if it is, I will generate a new JWT and return it to the client.
Where is a good idea to make this call? I was thinking that the getSession-hook would be a good place but I'm not able to use fetch from there.
HTTP-only cookies must be set via the Set-Cookie header. SvelteKit only has a few places where you can set response headers:
Svelte Endpoints
The handle() hook.
getSession() is probably not a good choice. The main purpose of this hook is create a sanitized version of the server context for the browser (like remove sensitive information like passwords/API keys.) It is called after the handle() hook, so it would be too late for setting any headers in the response.
getContext() may be a better choice because it is called before the handle() hook. So it is possible to get the refresh token and store it in the context until handle() sends it as a header. The context is accessible from handle() as request.context
Although not well-documented, fetch is available from all of these hooks. Simply add node-fetch as a dependency in package.json (not a devDependency!).
I think a problem with refreshing the token in the hooks is refreshing will happen on every request. This may add unnecessary overhead to your app.
I think the best solution is to wrap any API calls that need JWT tokens as SvelteKit endpoints. If the API call fails due to a stale token, the endpoint can get a new token and send it to the browser via Set-Cookie in the response headers. Note for this to work, you must ensure the endpoint is being called by the browser (not the server.) SvelteKit templates are executed first on the server, then again in the browser. If the endpoint is called from the server, the browser cookie will not be set.
My application has been built using SPRING MVC and I have exposed few Restful URIs. (Working Fine)
e.g - http://example.org/alert/alerts //get list of Alerts for the logged in user.
I have configured the application for Cross Site Request Forgery (CSRF) using OWASP CSRFGuard by following the link - (Working Fine) https://www.owasp.org/index.php/CSRFGuard_3_Configuration#Overview
The Restful services is currently been consumed by the same application's UI without having any issues. (Working Fine)
e.g - A data Grid which is part of the same WebApp is displaying list of Alerts by calling this Restful service (AJAX request)
Issue: When I try to access the same Restful services from a different domain/ Chrome Rest Client, it's doesn't return any data except for 302.
If I set The "unprotected pages" property in csrfguard.properties for the restful URIs, I am able to access the Restful service from RestClient/different domain.
Please suggest if I need to do any other configuration so that the same Restful services which are protected by CSRF can be accessed from a different domain/Chrome rest Client.
1.if you are generating CSRF Token at server side then
provide one get request inside that request validate session and send the created CSRF Token as hidden to client, now remaining request should be POST,PATCH,PUT or DELETE which are getting CSRF Token in every request header.
2. if you are generating CSRF Token at client side then from first request which is authentication or authorization get the value of Token and compare it with every request in your custom filter.
I am a newbie to REST webservice and have just created my first webservice.
In my service the user can create profile via simple form giving his desired Username and password.
Now how to check user credentials when the user logs-in ??
I mean i have a simple form which validates user has logged in but how to validate user when he is to perform various profile operation of add/update/delete ??
For example:
In FB you sign-in and it stores a cookie which has your credentials and when you perform operations like "Post Status",message a friend...etc... it doesn't ask for your credentials anymore because it has a cookie in which your credentials are there and it just uses that cookie...
But in REST we dont use cookie ,so the next option is HTTP headers.
And i want to know how to send and recieve user credentials via HTTP header .i.e
Basic HTTP Auth
Client Side
To send the credentials to the API you use the HTTP Authorization header, specifying the credentials in a form of Basic username:password. The username:password String has to be encoded using an encoding scheme called Base64. So an example header could look something like this:
Authorization: Basic d2lraTpwZWRpYQ==
As the rest specification states that the client-server communication should be stateless, you have to include the header with the credentials on every request. Normally you will use a session cookie on the client side to identify the user so that he does not have to enter his credentials on every request.
Server Side
To check the credentials inside your Jersey REST Service, you need to catch and intercept all the incoming requests. Jersey provides a concept called ContainerRequestFilters to do this. For example if you use Tomcat you could add filters of this type inside your servlet definition in your web.xml like this:
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
<param-value>your.package.BasicAuthFilter</param-value>
</init-param>
The referenced class BasicAuthFilter needs to implement Jerseys ContainerRequestFilter interface and override the public ContainerRequest filter(ContainerRequest request) method. Inside the method you will basically do the following:
fetch the Base64 encoded credentials from the Authorization header of the request
decode them (i.e. using javax.xml.bind.DatatypeConverter.parseBase64Binary())
use your UserDao (or other datasource provider) to check if the credentials are valid
return status code 401 Unauthorized if the validation fails (i.e. throw new WebApplicationException(Status.UNAUTHORIZED))
if the credentials are valid, simply return the request in order to delegate it to the Jersey Resource that is responsible for handling it
You can find a very good example in this blog post.