I need to log the server response body along with the client which requested it.
Tried mod_dumpio which logs the response body but it doesn't reveal
the client IP so I am not able to map the request and response.
The other option was audit log which seemed the exact tool I needed,
but it doesn't support logging actual response body as
yet.
Could anyone please suggest me an appropriate solution?
Related
I am confused by why the cors package allows the request to be processed even if the origin in the request header isn't white-listed. For example, res.status(202).send(await User.find()) returns a response with status code 202, but the data can't be loaded in the Chrome console.
Also, doesn't the browser send preflight OPTIONS requests to know what's allowed; why would it send cookies/credentials along a request with a disallowed origin?
Edit: Tried a post request on jsfiddle and the post request doesn't happen server side. When I said "why the cors package allows" it would be better to say why the browser allows.
CORS is enforced in the browser, not in your server. The server participates in setting headers that the browser can then use to determine whether the request should be allowed or not. But, it is the browser that ultimately decides whether the CORS request satisfies the requirements or not and the result should be passed through to the Javascript in the browser.
Thus, the request is sent to the server, response is received and THEN the browser decides whether the Javascript in the page is allowed to see the result or not.
In some cases where the request is likely to have side effects on the server (based on a set of criteria in the request), the browser will send a pre-flight request to get just the CORS info first.
Is it possible to check Http status code in Apache configuration as %{REQUEST_STATUS} for instance?
There is no such thing as a "request status", and no way for a server to interact with a browser in the middle of serving an error message.
HTTP is not an interactive protocol; the browser sends a request, the server sends a response, and that's it. So if the browser sends a request, and the application crashes, the server can send a response with 500 and the error details, or a response with 401 requesting the user to log in. Either way, that's the end of the conversation.
When it receives a 401 response, the browser can't say "here's the login details, carry on with the current request", it has to make a new request. It can make an identical request, which might reproduce the error message; but the original error message is gone.
If the requirement is to show a different amount of detail to different users, you need some notion of optional authentication, so that the server can decide immediately whether to include the error details or not, without an extra round-trip to the browser. I would suggest either:
Have a list of IP addresses which the application can check against; if the IP address of the request is in the list, include the error details.
Have a custom login system where you can authenticate and set a "session cookie" in the browser. If the user has an active session cookie, include the error details.
I have some logic in the web server to find out if the user is trying to do a DoS attack. But what's the correct HTTP response code to return for that? Also what's a good error message I can put in HTTP body to tell the user politely that he's got into the DoS attack path?
But what's the correct HTTP response code to return for that?
RFC 6585 suggests 429 Too Many Requests
The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting").
If the attack has compromised your ability to handle legitimate requests, then to those you might respond with 503 Service Unavailable.
Note the change in semantics - the person sending the bad requests gets a status out of the 4NN Client Error class, while those not at fault get a status from the 5NN Internal Service Error class.
what's a good error message I can put in HTTP body to tell the user politely that he's got into the DoS attack path?
Please stop that?
I have received some weird request URL in my TOMCAT access logs. which is
as follows:-
\x16\x03\x01\x01\"\x01" 200 40788
as clearly seen from above log, the server has given 200(success) response to the client(the one who is accessing above URL from our server).
I am really concerned whether the hacker is trying to post some malicious data on the server?
above request is in which format? is it in hexadecimal?
how should I convert above request URL to text format so that I will get to know
which resource he is trying to access or on which URL he is trying to post?
I am working in an API . I want to throw detailed error messages to the user. Now i am in a situation to decide what kind of error code should be sent or how to explain user if any error occurs in the application internally. For example if database connection fails , what kind of http status code i want to send to the user ?
Can anyone help ?
An HTTP status code generally refers to the status of the HTTP request itself, not the status of the application handling the request. Therefore, most server-side errors are covered by 500 Internal Server Error. Any additional info about the error should be described in the response body. For APIs, the response body will often be JSON or XML, so you can use those formats for your errors. Something like this:
HTTP/1.1 500 Internal Server Error
[headers]
{"status":"error", "message":"The request failed due to database connectivity."}
There are, however, two cases I can think of when you might want another status code. If the user has requested an API method that is not implemented, you might want a 501 Not Implemented, and when there is a temporary service outage, you can use 503 Service Unavailable.
More info about server-side status codes here.