Wt

I don't know of an iframe.js in Wt, so that must be related to some other software.

Wt will likely just treat it as a request for the internal path /libs/js/iframe.js and send the same HTML page as the response as you would get if you access /.

The whole request path /lib/js/iframe.js has nothing to do with my Wt application. I am not using any other software on the server. I am just using Wt. There are attempts being made at hacking the app. The request is related to that. Someone is trying a lot of request combinations to get past the Wt http server. The concern is that the two request mentioned above, one related to iframe.js and the other related to XDEBUG_SESSION_START returned the status code 200 which as per my understanding should not happen.

Do I need to handle such cases in the application?

Sorry, what I was trying to say was that it could be a bot using a canned exploit for some other software that you are not using. Sometimes websites also get tonnes of requests for wp-login.php, even if they're not running Wordpress.

If the path is not recognized as being part of a static resource path, it probably will result into Wt thinking it's a request for a new session with that internal path and return an HTML page just like it would if you accessed the application without a path. You'll see a new session being created for that request.

You can try to request that path yourself and see what response you get.

It doesn't necessarily hurt as long as they're not causing so much load it's leading to a denial of service. You can limit the number of plain HTML sessions in the wt_config.xml as a defense measure. You can also use setInternalPathDefaultValid(false), but then you'll have to make sure that all valid internal paths are marked as such, and I think you would also have to use progressive bootstrap.

I am using Wt just as a REST server and respond with WTemplate. I am not using any of Wt's widgets. In my application I do not have a WApplication object. So most of the security measures available in Wt does not work for this type of setup. Few days back I asked a question on how to use Wt in such a way that one gets all the security measures that Wt supports within a REST+WTemplate type setup.

@ Roel
If the path is not recognized as being part of a static resource path, it probably will result into Wt thinking it's a request for a new session with that internal path and return an HTML page just like it would if you accessed the application without a path. You'll see a new session being created for that request.

Will this not expose the server to DoS attacks?

Is there a way to blacklist IP addresses within Wt http server using the configuration file?

Few days back I asked a question on how to use Wt in such a way that one gets all the security measures that Wt supports within a REST+WTemplate type setup.

Well, a lot of the security measures in Wt are inherent to the widget system. You'll certainly get some XSS protection with WTemplate, though.

Will this not expose the server to DoS attacks?

Yes, to some extent. The plain HTML session limit is intended to prevent that. Even then, someone who's crafty enough could still try to mount a DDoS attack, but then it kind of gets outside of the scope of what Wt offers and you'd have to look at a reverse proxy setup. Blacklisting IP addresses is one of those things that's not in Wt, but you could handle that in a reverse proxy or firewall.

So if you're not using WApplication, do these requests arrive at one of your WResources? Otherwise it normally should return a 404.

Sorry, did not read the last paragraph about DoS attack and the suggested solution.

Looking at the suggested solution on limiting plain HTML sessions in wt_config.xml and/or setting setInternalPathDefaultValid(false), it occured to me that if there was a way to register all valid endpoints with Wt, either using wt_config and/or a C++ API, then Wt could just reject any requests to other non-existent endpoints immediately upon arrival. That would be a very important security measure for Wt. Ofcourse this feature has to be disabled by default and only enabled if the developer has registered valid endpoints via wt_config or using the C++ API.

So if you're not using WApplication, do these requests arrive at one of your WResources?

Yes, the REST endpoints are hosted by WResources.

What I'm saying is that one of those WResources is returning a 200 response. The normal behavior for Wt is that if no entrypoint or file in your docroot matches, you get a 404. For example, if you try to request //libs/js/iframe.js from the urlparams example, you get a 404. That is already Wt's default behavior.

What I'm saying is that one of those WResources is returning a 200 response.

Yes, that is true. I have only two resources. One resource at "/" endpoint that returns the home-page(a WTemplate). The other is a form submission endpoint at "/book", which returns another WTemplate as a response when a user submits a form on the home-page. I am not doing anything fancy. The webpage is at https://pndr.ml

The normal behavior for Wt is that if no entrypoint or file in your docroot matches, you get a 404....That is already Wt's default behavior.

Actually that's what I was expecting, but that is not what is happening in the above mentioned two cases related to "//libs/js/iframe.js" and XDEBUG_SESSION_START. All the other illegal requests that the server receives do either return 404 or 400. It is just the two aforementioned requests that return 200. My suspicion is that in the case of the iframe.js request, the extra "/" at the start plays some mischief. And in the case of XDEBUG_SESSION_START, as it is related to debugging PHP applications and is passed as parameters it could just be getting passed to the endpoint.

For example, if you try to request //libs/js/iframe.js from the urlparams example, you get a 404.

No, it does not. Try this: http://localhost:8080/users/lib/iframe.js and http://localhost:8080/users/lib There is no 404. Even when I remove all entrypoints except "/user"
I still don't get any error when I visit http://localhost:8080/users/lib or http://localhost:8080/users/lib/iframe.js

Maybe there is a gap in my understanding and I am missing something.

Sure, it returns 200 if you put /users in front of it. Wt matches the longest prefix that it can.

If you put a resource at / then anything that does not match another resource will match that resource. Anything extra will be reflected in Request::pathInfo(), so if you want to return a 404 in any case where it's not just /, then you will have to check pathInfo() and return 404 if there's anything extra.

if you want to return a 404 in any case where it's not just /, then you will have to check pathInfo() and return 404 if there's anything extra.

Thank you for this info. I will update my code to handle unwanted requests to the server.