Tag Info

New answers tagged

1

These requests are caused by Adware:Win32/Adpeak malfunctioning (yeah, believe it or not, even malware can malfunction). It sets up a proxy server on the infected systems that injects script tags in all HTML content that passes through it, similar to <script type="text/javascript" id="2f2a695a6afce2c2d833c706cd677a8e" ...


0

Adding to Thomas answer, you should always remember to make your app check the certificate received in the ssl handshake. It is YOUR job, as a mobile developer, to correctly verify if the certificate is valid (if your server uses a self-signed one, be sure to pin it inside the app), or your users will be prone to MITM attacks and BAD things tend to happen ...


2

Correct me if I am wrong, according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. its only after the tunnel is created that the complete GET or POST request is sent. No, this is not a HTTP CONNECT, it is a TCP connection request. The HTTP CONNECT method is only used if you are connecting over a HTTP proxy ...


1

according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. Not really correct. CONNECT is only used together with proxies. And even then it does only establish a tunnel directly to the other side, but not yet the SSL tunnel. The SSL tunnel is with and without proxy only established with the SSL handshake ...


1

The browser checks both fingerprints. The idea behind that is if it is possible to create a fake certificate with the same MD5 or SHA-1 hash, there is a much lower (almost zero) probability the same certificate second hash also matches. This could be called: Dual Hash Fingerprinting. Both MD5 and SHA-1 are considered vulnerable in theory (MD5 also in ...


0

If you use HTTPS, then you will benefit from the protection of SSL between the browser and the Web server, and nowhere else. HTTPS is not Telnet; this is another protocol; meaning that a Telnet client will not use HTTPS or SSL, even if you find a way to trigger it from an HTTPS-served Web page. If I understand your case correctly, then you have: Several ...


0

If the webserver is running on the same box as the telnet system (or directly connected on a physically secure connection), then you could safely relay information to the webserver and have it relay it, via telnet, to the system that you want to talk to. The important thing to realized, however, is that your communication is only protected between your ...


0

The browser is just executing the telnet program on your local system. This will establish its own connection to the terminal server, independent from the browser connection. So it will be insecure, even if the link itself was served via https. Check your console server if it support SSH instead, because SSH (available on Windows with putty and others) will ...


1

Since access has been sufficiently restricted, the weakest link is the HTTP request. This is especially true based on comments regarding the poor interfaces of the IP cameras. They likely won't do well if irregular requests are sent. Therefore consider a Web Application Firewall (WAF) such as ModSecurity as it will provide more flexibility over what ...


-1

Yes it does If TLS/SSL negotiation fails, then the browser fallback to HTTP (while staying over HTTPS), the same way it can fallback to SSL3. I took this screenshot while browsinghttps://security.stackexchange.com/questions/71512/is-it-possible-to-force-a-browser-to-use-http-in-an-ssl-enabled-https-website:


5

A page which is secured with SSL (or TLS for that matter) cannot be accessed via HTTP, as that would mean that the page is not secured anymore. If I rephrase the question: Is it possible to access a particular page of a HTTPS secured website via HTTP, then I would say that is possible, but very INsecure. Moreover, the cookie with the session ID will ...


2

Yes it is of course. The simplest example is the user who just submits the request as http://..., either unconsciously or by will. The (potentially malicious) web server could do that too, by just sending a 30x redirection or a page with all further hyperlinks pointing to http:// instead of https:// Example for the latter one: connect to ...


2

I'm answering my own questions but for future seekers, I found this great article: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication. Maybe I didn't explain my question well but this was the answer I was looking for. -- UPDATE -- Rory Alsop, asked to post a summary. You should definitely read the source. But in case you ...


5

You cannot trust the client, ever. A malicious user may abuse legitimate client software (theirs, or someone else's) An attacker may reverse engineer enough of the API to pretend to be a legitimate client Instead of trusting the client, work to ensure that the client's input is trustworthy. input validation input sanitization schema compliance velocity ...


3

The security differences between an HTTP and HTTPS proxies varies depending on what you are routing through them: Clear text (ftp, telnet, HTTP): If the proxy is HTTP, the traffic is transmitted in clear text between your computer and the proxy, and clear text between the proxy and the final destination. If the proxy is HTTPS, the traffic is encrypted ...


1

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 ...


4

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.


1

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 ...


6

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.


6

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: ...


5

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 ...


0

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 ...


0

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.


0

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.



Top 50 recent answers are included