I have an assignment of testing an API which is supposedly vulnerable to CSRF.
In order to test the API, I'm thinking log into the website from a browser (The website that has the vulnerable API), I also need to run a web server (Publicly Accessible from the internet) that has the CSRF script running on it. Then I would click a hyperlink that has the script embedded in it.
How would I go about setting up a web server?
Is there a simple way of spin up a publicly accessible web server that has the CSRF script running on it?
Note: I have access to AWS.
Related
I currently have an API running on Nodejs Express where you can get or upload all types of files (images, videos...) as well as simple json responses.
I would like to connect Sveltekit to this API but it is secured with a SSO so I need to provide an access token for each request.
I already get the access token from the SSO (oidc) on sveltekit.
Solution 1:
a service workers intercept requests to the API and add the access token.
Problems: I don't want to build every time but as the documentation says: service workers only work in the production build, not in development
Solution 2:
send requests to the svletekit backend and then pipe them to the API with the access token
Problems: Works only for basic requests but not for stream, it seems that it is supported recently (https://github.com/sveltejs/kit/issues/5344) but there is no documentation or example and this solution requires more resources (requests should be from the browser to the api)
Solution 3:
Hooks externalFetch
This function allows you to modify (or replace) a fetch request for an external resource that happens inside a load function that runs on the server (or during pre-rendering).
Problems: It doesn't work for requests like the src of an image
Any idea ?
edit: Solution, with the new version of sveltekit node-fetch has been replaced by Undici and the streams are functional, so it is possible to pipe requests from the backend.
For the dev it work well but it's not the best solution for production so you can use both depending on the environnement.
Here is what I'm trying to achieve:
Right now, the Desktop App, Auth server and API are working correctly, I can get my JWT and use it to call the API.
Both web apps are already in use, subdomain1.domain.com use NGINX auth_request, cookie and sessions on an old auth server to get access.
Web app in subdomain2.domain.com use session, and connect to the API with an app token.
And, all these servers are part of the same domain.
So, is it possible to share the JWT from my Desktop app with browsers? We generally use Chrome.
The desktop app use Python 3, and most of the user will be using Windows.
If I can't, and I'm pretty too stupid to do this working, my other concern is, can my browser use that JWT on all web app once it connected get it from auth server? All servers shares the same main domain.
Our web server can be using Apache2, Nginx, Nodejs or Flask (python), which is kind of annoying when trying to make things like that works.
I could use cookie for .domain.com, and store the jwt inside, am I right?
If yes, is this really the best idea?
The idea behind it is:
User log in the app or browser
JWT is generated
JWT is shared between app and browser (not sure about this one)
JWT is used on all subdomain by the browser
What is your advice on this?
I think you can use a cookie in that case with no regrets. Just configure it correctly that every domains you need to have an access to this token.
How can authentication details be passed to a shiny app in a a secure way?
The shiny app is hosted on a a Linux machine with Shiny Server (Open Source version) and should only be accessible after login on another webpage (through SAML) which is hosted on another Linux machine. The shiny app should have different functionality, depending on user rights. So, that information has to be passed to the shiny app at startup.
How can this be achieved in a secure and reliable way?
The only options I could think of were:
Getting the IP-adress of the user and making a request from the other webpage to get the user-rights of that IP.
Passing user-rights within the URL params and using those with parseQueryString(session$clientData$url_search) at shiny-startup.
The first option would make the app depend on a third-party service that gives me the IP and I dont know how a proxy, Vpn etc would interfer with this approach and how reliable it would be. The second option doesn't really seem secure or professional.
What other options would there be?
I am using Angular 5 to send post request to send SMS through Bulksms : http://bulksms.com/
When making the request from Angular (client), I am facing this issue :
Origin http://TTTT:4200 is not allowed by Access-Control-Allow-Origin.
How can I correct this issue in BulkSMS ?
Regards,
Your browser's same-origin policy is restricting your Javascript code from accessing a third party (i.e. api.bulksms.com in this case) in the way in which you hoped to do it - and CORS (Cross-Origin Resource Sharing), which is a mechanism to relax those restrictions, is not relaxed enough to allow these requests (from you as an untrusted third party) either.
Wikipedia Same-origin policy : "Under the [same-origin] policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page". The Wikipedia page contains some good examples of the sorts of malicious Javascript code uses that the same-origin policy tries to limit.
It is important to note that these restrictions are only enforced by browsers: HTTP client code that is not running under a browser typically doesn't care about any of this.
For development purposes, there are some tools that can make your life easier - for example, you could use live-server to run a simple HTTP server which serves up your static files, while also using its --proxy option to route requests to api.bulksms.com and solve your same-origin policy problem in the process.
For production, a typical solution is to route your AJAX requests, which are destined for the third party service, via your own server (the one serving up your Javascript files to your browser), or a reverse proxy (which would front both your own and the third party service). If there is a server side to your application, you can make the HTTP requests to api.bulksms.com from there, using an HTTP client, and then have your Javascript code talk to your own server, to indirectly make the requests to bulksms.com. This also gives you the opportunity to add authentication headers on your server side, without your Javascript code ever having to know them (e.g. if you have one bulksms.com account, and many users able to use that account via your Angular app, but who should not know your credentials). Similarly, you could impose limits on what your Angular users can do in this way (e.g. to limit the number of SMSs they could each send per day).
I'm trying to figure out, how to use OAuth 2.0 to access Google APIs from my web app. The problem is, that the protocol require developer to register redirect_uri (URL of page receiving access token). But my application can be distributed to many customers and can be hosted on endless number of servers. There is no way to know redirect_uri beforehand.
Google offers another option for installed applications, but I cannot use this variant neither. Auth server returns access code in window title and this information cannot be accessed from javascript of our page (JS cannot access content of window opened using window.open(); if that content comes from different server).
To conclude:
Cannot use method for web applications, because I don't know all URLs where will our app run in the future.
Cannot use method for installed applications, because window title is not accessible from our JavaScript code.
Is there any recommendation, how to use Google's OAuth 2.0 from distributable web application running on a lots of servers? Thank you.
Are you sure you cannot access the window title? If your app is opening the window, it should be able to access it. It should be possible to do this in a similar way you would do it in a mobile app.
If all attempts fail, you could set up a proxy server (that has a known redirect URI) and hands out the Google tokens to all your clients. Or better each of the apps could have its own proxy server - the server it was downloaded from. But then if each OAuth client can only have one redirect URI, each app would have to be a separate OAuth client.