just wanna ask if there is a way to call passive scanning specifically without spidering, as I have the url list and use importurl api to inject urls into zaproxy.
I did examine the api documentation for pscan module seems it does not have api that starts the passive scanning.
Related
Trying out cloudflare for ddos protection of an SPA webapp, using free tier for testing.
Static contents loading is fine, but API calls became very slow.
From original <50ms for each api call to around 450~500ms each.
My apis are called via a subdomain eg apiXXX.mydomain.xyz
Any idea the problems or alternative fast ddos protection solution?
Cloudflare has created a page to explain the configuration you have to do when proxyfing APIs :
You have to create a new Page Rule in which you have to bypass cache, turn off Always Online and Browser Integrity Check options.
If you do not configure this, you may have slow response time because all those options are enabled by default on API calls.
Here's the link to create the configuration : Cloudflare Page Rule for API
I'm creating load testing with JMeter.
We have A Single Page Application (React).
Let's say I need to check the endpoint
GET /foo
When you go to that endpoint via the browser it triggers API endpoints (javascript fetch) to retrieve data. Let's say 2 endpoints
GET /api/fooData, GET /api/fooCalendar
My question is: If I request GET /foo with JMeter (or Postman for instance), will it trigger the other endpoints behind the scene like a normal user flow, or I would need to manually check all the endpoints that are being triggered?
As per JMeter project main page:
JMeter is not a browser, it works at protocol level. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does (it's possible to view the response as HTML etc., but the timings are not included in any samples, and only one sample in one thread is ever displayed at a time).
So you will have to create separate HTTP Request samplers for each JavaScript-driven calls. If the calls are made in parallel - it would be better to put them under the Parallel Controller as JMeter executes Samplers sequentially (upside down)
My VueJS application relies on a Java backend. This Java backend serves all REST endpoints for providing the data.
When a user performs a checkout the backend responds with a redirect url and redirects the user to that URL. This is done simply like that:
window.location.href = redirectUrl;
As soon as the payment process is finished on the external page the payment provider redirects the user to a return_url which in this case is my VueJS front-end. However the external system sends the return_url in a POST request directly to the front-end which cannot be processed in the as there is no endpoint listening.
What would be an approriate way handling this? As far as I know, VueJS doesn't have any possibility accepting POST requests.
TLDR; It is the responsibility of any external payment gateway system or similar system like OAuth/OpenID to redirect to the calling app via simple browser redirects (via HTTP 302 and 303). So, you should ask/configure external payment provider to follow the standard workflow.
In theory, you should never encounter this problem as POST is typically an Ajax request. Imagine you are on external payment page and when the payment succeeds, external JS is making the POST call and hence the payment page should then take responsibility of redirecting to the appropriate page by reading the reponse.
Now, the second possibility is that payment page is using traditional FORM submission via POST method type and giving back response as JSON or equivalent body. In this case, you should have a server side script (on your ui-server) that would listen for this call and then load the front-end application built with Vue.
If your UI is being served by Java back-end, then it should be simple job of having a Servelet or JSP.
Modern single page applications use routing mechanisms which don't have to rely on fragments or additional url parameters, but simply leverage the url path. How does the browser know when to ask the server for a resource and when to ask the single page application for a spa-page controlled by a router? Is there a browser API which makes it possible to take over the control of url handing which is then taken over by e.g. the vue-router or another routing spa library?
In Vue Router (and I assume other libraries/frameworks are the same) this is achieved through the HTML5 history API (pushState(), replaceState(), and popstate) which allows you to manipulate the browser's history but won't cause the browser to reload the page or look for a resource, keeping the UI in sync with the URL.
For example, observe what happens to the address bar when you enter this command in your browser's console
history.pushState({urlPath:'/some/page/on/stackoverflow'},"",'/some/page/on/stackoverflow')
The new URL is even added to your browser's history so if you navigate away from the page and come back to it you'll be directed to the new URL.
Of course all these URLs are non-existent on the server. So to avoid the problem of 404 errors when a user tries to directly access a non-existent resource you'd have to add a fallback route that redirects to your index.html page where your app lives.
Vue Router's HTML5 History Mode
React Router's <BrowserRouter>
How does the browser know when to ask the server for a resource and
when to ask the single page application for a spa-page controlled by a
router?
SPA Frameworks use routing libraries.
Suppose your javascript app is already loaded in the browser. When you navigate to a route that is defined in your routes array, the library prevents an http call to the server and handles it internally in your javascript code. Otherwise the call is forwarded to the server as a GET Http request.
here is an answer that discribes this behaviour with a clear scenario
I've been looking at backends and APIs for a while now. It seems that sometimes devs will build a regular backend (in say a language like PHP) that handles all the backend matters and sometimes devs will instead choose to build out their backend through an API and then use their own (and possibly other) sites to pull data from this API.
I was wondering this:
Say I want to build a regular backend using a server-scripting language like PHP, which I will use to not only render my main website, but will also allow me to do other server-side scripting etc. Then say I want to use this data from the current site and make it accessible to another site of mine through API calls. Will it be possible to build an API on top of a regular backend?
If the answer yes, how complex can it get to achieve something like this?
What tools or design strategies (if any) would you have or have used for achieving this?
This is an old question, but since I'm here, I may as well provide an answer for anyone wondering. Joe is asking about server-side web APIs versus regular server-side code.
Yes, you can have a "regular" backend and an API backend exist at the same time. If your backend is in PHP, you can refactor and extend your code to handle API requests.
Like Patrick Evans said, an API is the backend. If your backend PHP code communicates with a database to manipulate or retrieve data, then you can consider this an API transaction. Whenever your backend receives a request, evaluates/actions that request, and returns a response, it is essentially acting like an API.
Let's say you own example.com, with an index.php file in the root directory - so when a user requests example.com in their browser, this index.php file is processed and served to them. Now, you can set up this index.php file to handle both regular page requests (i.e. the php script returns an html template that is rendered by the browser) and API calls. This can be as complex or as simple as you want it to be.
The best way to handle this would be to assign different routes for rendering your main webpages and API calls. You can set up routes in the following way...
example.com/index.php?route=api&data=users can be handled by your 'API code' in index.php to return a JSON response containing a list of all the users in your database, while example.com/index.php?route=home will just return your website's home page.