Tag Info

New answers tagged

1

In spite of being possible to read/write data to SSL/TLS channels as with vanilla TCP/IP sockets, in Java or C or whatever, SSL provides you the concept of SSL session, which can be kept across several TCP/IP connections. Thus, IMHO this makes SSL a session layer protocol (I wonder why someone came up with the TLS name...).


0

If you are passing authorisation token via http headers then you need to have a client side logic to pass this to server every time you make a request. A skimmer can look for this in your client side code and can hijack your user session with Java script. But if the same info is passed via cookies then it is the browsers responsibility to pass the cookie ...


2

Basic auth credentials are transmitted with each and every request by the browser. Hence why you cannot traditionally "log out" without closing the browser. The reason why this approach works is because the browser is stateless. Normally when it sends a GET/POST/HEAD request it receives a 200 OK response. If it receives a 401 response it will prompt the ...


3

In the case of CRIME, the attack is on the client. Hostile Javascript in the client triggers requests to the server, that the attacker observes from the outside; and (that's the important point here) the attacker can block the outgoing request. The attacker needs to see the encrypted records, but not necessarily to let them go all the way to the server. ...


-2

I also got stuck here for some time. It turns out that our WebGoat is Linux version. Linux only uses LF, so when encoding the parameters, only use %0a, instead of %0d%0a.


12

Implementing your own SSL is not a small endeavour. It takes some effort to make it run at all; it takes a lot of effort to do it securely. The cryptography in SSL is subtle, and especially the implementation of the symmetric encryption (with block ciphers) is known to have some vulnerabilities if the decryption and MAC verification are not done with the ...


0

This is called a 403 phishing attack, and the only way you can prevent it is to prevent user-generated-content from containing links to external resources that are rendered on your pages, like images. Fortunately, it's not a particularly common attack, but it can be concerning, particularly if the credentials users use on your site are more likely than ...


2

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



Top 50 recent answers are included