Hydra gives a lot of false positive, at least this is my experience with it. You can try to use wfuzz instead with this syntax for post request wfuzz -z file,wordlist/others/common_pass.txt -d "uname=FUZZ&pass=FUZZ"
You will know the right password when you see the 3xx code as a response from the server.
Unless you specifically configure your web browser to use a client certificate for the site that you're connecting to, your browser does not use a certificate to make the SSL/TLS handshake with the server.
Instead, your browser receives the server's certificate, and verifies that it was signed using a certificate in your browser's or OS's certificate ...
This is a great security question. One must understand the mechanics of what they work with to ensure they are building secure software.
There is no added significant security risk when a server has access to cookie information. Servers are already a privileged system that needs to be strongly protected.
[Comment] ...how can [a] server ...
I think this depends on the HTTP library that handles the requests, for example, in theory if the content of a POST message is json and the content-type is set to text/html the responsibility of give an error will be from the application (the content ins not text and is json), however depending on the HTTP library this check can be done on the HTTP library, ...
Let us try to answer the questions one at a time:
Is it correct that putting user passwords ..., while web applications do? Does HTTP know to look for user names and passwords or for other specifics in message bodies?
At the HTTP level, the body is an opaque stream of bytes. But it is common to use HTML form answers to give passwords for form ...
Is it correct that there are various ways that a HTTP client can authenticate itself with a HTTP server?
Yes. There are many, many ways. Custom authentications schemes are common.
Are the following such ways?
authorization header: for various authorization protocols (e.g. basic, digest, ...)
digital certificates: as used in HTTPS.
The remote API may be designed this way, so any other http methods except GET or POST are not used, for example:
Anyway, you will have to read an API spec and figure out how to add or delete items, so it's 50/50 argument that one is better than another. I prefer having only GET and POST.
I would say implementing the OPTIONS method, in itself, is not a significant security risk. Yes, it nicely enumerates which other methods are implemented by a server, but it is in the handling of those other methods that the potential for danger lies, not in the reporting that they are handled.
For example, the TRACE method can be a vector of attack. If you ...
Just for some thoughts, without saying this is a proper recommendation:
Check which levels of flexibility you need - if some of these headers need to be set in special circumstances (eg. depending on the state of your application), you maybe have no chance but to keep them in the application.
If there are multiple apps behind the WAF, can you be sure that ...
From the perspective of the client, it does not matter where these headers are implemented; only whether they are implemented at all.
But, from the perspective of deployment, a WAF should be treated only as an additional line of defense and not as the single line of defense. This means that proper input checking should be done in the web application itself ...