New answers tagged http
10000 outstanding requests in a single HTTP connection is certainly evidence that something has gone wrong. There are three likely possibilities here: The server has partially crashed, such that it is accepting requests but no longer processing them. The client is sending requests faster than the server can process them. Something has changed in the ...
Redirection the user after a successful login is common in the most webapps. For instance when the user try to access the dashboard directly within its url, the system keeps the requested url and brings the user to the login page, after user signed in he is redirected to the dashboard not the homepage or something.
There are circumstances where a HTTP server will return a list of supported methods for a given resource in its Allow response header, according to RFC 7231 (the new RFC for HTTP 1.1 semantics): First in the response to an OPTIONS request, either on a specific resource path, or on the special * path (which would mainly describe the capabilities of the ...
Per RFC2616, the OPTIONS method should return the supported methods. Keyword is should since this isn't always the case. As the prior posts have already pointed out each method needs to be tested separately to be sure.
As there are only few methods (OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT), you can use a script and nc to send a request to all allowed methods and parse the results: for method in OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT ; do echo -e "\n\nTrying $method\n\n" echo -e "$method / HTTP/1.1\nHost: server-hostname\nConnection: ...
The only way to identify the methods supported by a web server is to try each one and evaluate the response to determine if it indicates the method is supported or not. You can't simply query to ask which methods it supports; it won't give you a list. That said, there are better tools than nc. Nmap and metasploit both support HTTP method scanning and ...
If you aren't concerned about the user being prompted, then you intercept most HTTPS connections by proxying them. Instead of allowing the user to directly connect to the site they've requested, you connect them to a intermediary you control, and then use it to connect out to the to site that they've requested. This way the client's HTTPS session is ...
You can not force any website to use http instead of https. You can do only one thing create your own certificate and attach in all browsers then whenever you will in between client and server it will not prompt to the user. Other than that you can also try downgrade the ssl version to use the known vulnerability against ssl.
For the most part, a token-based authentication solution would be preferable, however Basic Auth does offer maximum interoperability and downward compatibility. Any client (even a shell script with curl) could consume your service easily, as long as they had valid credentials.
Use IPSec to create a secure VLAN. Better performance than HTTPS and more secure(no payload is in plaintext anymore). You can use your own PKI infrastructure and with some custom code you can integrate strongswan easily in your systems; it provides hooks for nearly every stage of the connection. Plus you also get client authentication (machine certificates). ...
The operation performed is similar to server authentication with the following differences. After sending the message ServerKeyExchange, the server indicates to the client that it wishes to authenticate the client via a CertificateRequest message; the client then sends its certificate. The TLS handshake operation is performed normally but after sending the ...
You can try looking if you can get the server to display a native error page. Error pages can be customized by a web developer, but when they aren't, they often reveal a lot of information about the web server. For example, this is the 404 Not Found error page of Apache 2.2.4 running on Unix: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> ...
Why not just use nmap to detect what web server software is being used?
If a website does not use a custom built server to modify the HTTP headers, you can try by examining the order of arrangement in the HTTP response fields. From OWASP: Apache 1.3.23 server: HTTP/1.1 200 OK Date: ... Server: ... Last-Modified: ... ETag: ... Accept-Ranges: bytes Content-Length: ... Connection: ... Content-Type: text/HTML Microsoft IIS ...
TOTP is an HMAC. It just happens to be an HMAC of a timestamp with some granularity where the passwords need to be rotated. Note that with either a time-based HMAC or some other HMAC, an attacker with a copy of a legitimate client can extract the shared key and use that key to forge requests from their client.
No, you can't conclude that from the 403 error. If the server returns a 403 error for a directory, that just means you aren't allowed to list the directory contents, or that the directory has an index page that you aren't allowed to access; this is very common for cgi-bin directories. You can, however, conclude that you are not vulnerable because there are ...
The url encodes a Windows Codepage 1251 encoded string, containing (harmless) russian error messages. The transcoded url is: /767/browser-wars-side-show-how-natty-handles-the-load/+++++++++[+Активация+]+Result: использован никнейм "azazalolxd"; вошли; не нашлось формы для отправки; Google translator gives: [ activation ] Result: used the nickname ...
If you have coded your application to properly sanitize user input, encode special characters before they get to the back-end, and reject data that is unexpected, you should have nothing to worry about.
Regarding your "password" approach, this is exactly how API keys work. If you want to use Facebook's API, or Stack Exchange's API (etc., etc.), you'll need to get an API key to identify yourself as a particular user of the API and send that API key with every request. Thus, every request that hits the API can be traced back to an originating user. This also ...
You can use HTTPS together with client certificate authentication. Then you can ensure that only clients with a valid certificate are able to use your site. The client certificate will then replace the password you mentioned and the user will not notice the magic done in the background.
Some things to consider: make sure you set the domain/path of the cookie so that only your domain (and no sub-domains can read it) You seem to be using HTTP rather than HTTPS. This makes your cookie subject to eavesdropping. Consider using a HTTPS session and a cookie using the secure attribute. 90 days is a long time to hold such a session open. The ...
Top 50 recent answers are included