I was doing a automation testing on my web application with SOAPUI, I have found a bug which is http method fuzzing basically it means "HTTP Method Fuzzing
An HTTP Method Fuzzing Scan attempts to use other HTTP verbs (methods) than those defined in an API. For instance, if you have defined GET and POST, it will send requests using the DELETE and PUT verbs, expecting an appropriate HTTP error response and reporting alerts if it doesn't receive it.
Sometimes, unexpected HTTP verbs can overwrite data on a server or get data that shouldn't be revealed to clients."
Can anyone knows how I can solve this issue or how I block the HTTP request other than GET or POST which may remove this bug.
I am using Node.js and express for my web application.
Please check the images:
Image 1
Image 2
Related
I am attempting to use the endpoint https://firestore.googleapis.com/v1/{parent=projects/*}/databases with more data needed per the documentation on Google's docs.
The goal is to be able to make this request with a standard http utility such as cURL.
I have attempted performing the request manually through the GUI with the Chrome network tab open, and I saw a request being made: https://firebasedatabase.clients6.google.com/v1beta/projects/XXXXXXXXXX/locations/us-central1/instances?databaseId=my-database&validateOnly=true&alt=json&key=secretkey
Per trial and error on another endpoint, I have found that the key parameter can be replaced with a Bearer Auth token in the header. Other than that I am at a dead end.
Status code 400 Bad Request is used when the client has sent a request that cannot be processed due to being malformed.
Status code 404 Not Found is used when the requested resource does not exist / cannot be found.
My question is, when a client sends a request to an endpoint my API does not serve, which of these status codes is more appropriate?
Should an endpoint be considered a "resource", and thus a 404 be returned? My issue with this is that if the client only checks the status code, they cannot tell the difference between a 404 indicating that they got to the correct endpoint, but there was no result matching their query, versus a 404 indicating that they queried a non-existing endpoint.
Alternatively, should we expect that a client has prior knowledge of all available API endpoints, and thus treat their request as malformed and return a 400 if the endpoint they are trying to reach does not exist?
Maybe this depends on whether the endpoints are REST or not. If they are REST endpoints, the client should not need prior API knowledge, but be able to learn about all relevant API endpoints by navigating the API from a single root endpoint. In such a case, I guess 404 would be more appropriate.
In my specific case right now, this is an internal (non-REST) HTTP API, where I expect the client to have prior knowledge of all API endpoints, so I am leaning towards 400, to avoid issues where 404 from accessing the wrong endpoint could be misconstrued as a 404 indicating that what they sought from the correct endpoint could not be found.
Thoughts?
As a convenience, many modern APIs provide human-readable endpoints for developer convenience. The intent of REST, however, is that URLs are treated as opaque - they may happen to contain semantic content, but can't be relied upon to do so. There's no such thing as a "malformed" URL. There's only a URL that points to something and a URL that doesn't.
Now, that's the REST dogma (and arguably also the HTTP 1.1 spec). That doesn't mean it's what you should do. If you have a single internal client for your API, and that's not going to change, you have a lot of flexibility in designing your own standards. Just make sure to document them, especially those that might confuse the guy straight out of college that they hire to replace you when you move on.
The flow is SAP NWAS 7/Java AS ---> Apigee On Premise--->Apigee OnCloud -----> Backend. and back.
Backend is posting a response of appx 17 MB back. I have streaming enabled both on cloud and on premise Apigee. But the sap NWAS client states that only partial response is received .
When we invoke from POSTMAN however, we are getting complete response.
Please suggest where the problem can be?
Since Postman works fine for you, it seems like it might be a problem on the client side. So, it's possible that the client requires more info on the response in order to be able to display the content e.g. Content-Type header. Another way to troubleshoot this issue is to send a cURL command to the resource in Apigee and store it in the filesystem to validate that not only Postman can parse the response. e.g.
curl http://yourresourcehere/images/12344 > img12344.png
I am using webMethods from the SAG and it seems if the service
pub.client.http
throws an exception on status code 401 "Unauthorized".
This leads me to the problem that I cannot handle the status code because nothing is written to the pipeline.
getLastError
does contain the string "Unauthorized" but not the status code.
Except that I do not want to start parsing exception messages...
Any ideas?
The output parameter header from the pub.client.http call should contain the information you’re after:
header Document Conditional. HTTP response headers.
Key Description
lines Document Fields in the response header, where key names represent
field names and values represent field values.
status String HTTP status code of the response.
statusMessage String HTTP status message of the response.
See the webMethods Integration Server Built-In Services Reference page 122 for more details.
Asked a SAG senior consultant.
This is the normal behavior.
There is no flag which you can set to enforce suppression of this exception...
You can suppress the exception and have the HTTP 401 status returned like any other HTTP response. Go to the IS Admin Extended Settings and set:
watt.net.http401.throwException=false
Note this is a server-wide setting, so it will affect all your applications/services that use pub.client:http.
According the comment from #Hugo Ferreira probably there are ACL restriction whether inside your webMethods environment, or your client URLs.
Things you should consider:
Do your webMethods server located inside closed environment wherein need to get connected to proxy to get to the outgoing request. Which is likely you can investigate by run web-browser program directly from your wM server towards the URL address (i.e using SSH to run firefox in my case and popup appeared)
The client that your request will go to, have HTTP for authentication requests
Solution
To pass this all you need to do is input the auth user/password or any other auth mechanism i.e kerberos, token, etc. inside the pub.client:http
I've implemented a RESTful API using ASP.NET Web API (included in ASP.NET MVC 4).
When a client requests my services with an unsupported Content-Type (like "text/plain"), I get the following exception:
System.InvalidOperationException: No MediaTypeFormatter is available
to read an object of type [...] from content with media type
'text/plain'.
and my service returns a HTTP status code 500 and an error is logged/reported (I'm using ELMAH).
Unfortunately, I do not find an easy way to "catch" this type of unsupported client request. IMHO, the service should return a status code like 404 (not found) or 400 (bad request), because the error is not a server error (but a client side error).
In another SO question I found this answer How do I configure the status code returned by my ASP.NET Web API service when the request has an unsupported Content-Type? which shows a possible solution by implementing a custom DelegatingHandler.
So my question is: Do I miss something? Is there any ASP.NET Web API built-in functionality that targets this problem...
I finally "fixed" the problem with a custom DelegatingHandler similar to this implementation
How do I configure the status code returned by my ASP.NET Web API service when the request has an unsupported Content-Type?.
You can find my implementation here: http://blog.janjonas.net/2012-09-05/asp_net-mvc_4_rc-web-api-return-http-status-code-4xx-invalidoperationexception-no-mediatypeformatter-available-read-object-type-content-media-type
You can certainly use your own custom DelegatingHandler or you can make your custom HttpModule
which will implement the IHttpModule and check the current http request and validate the request.