Tag Info

New answers tagged

1

It's a server configuration issue. No, I don't know why your server is configured to do this, since it's generally a bad idea. Using my general-purpose HTTP diagnostic tool, wget, to retrieve https://www.w1office.com/CSS/all.min.css, I get: Connecting to www.w1office.com|91.151.215.29|:443... connected. HTTP request sent, awaiting response... 200 OK ...


7

To expand on Thebluefish's answer, the form submission process appears to use HTTPS (an encrypted protocol) for the credit card element to https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing when I am looking at the page. But this does not mean this setup is safe to use. The overall setup is very vulnerable and needs to be fixed. I ...


-1

Encryption could have been done with javascript before the form is posted. To do so, the encryption algorithm and public key has to be sent to the client if using asymmetric encryption. For symmetric encryption, both algorithm and key must be sent. However, I have not found any javascript encryption library or function used in the page. An example of such a ...


3

If you look at the source code regarding the credit card form, you can see the following: <form name="form" method="post" action="https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing" id="payForm"> Therefore the form submission is over HTTPS. This should be fine in ensuring your credit card details are not stolen, though your ...


2

If there is code executing in the same context of your web application, whether it was part of a XSS attack in the browser, or some malware/virus on the users machine, it would be difficult (impossible?) to differentiate those requests from your own. If the attacker has access to the computer, they could also just steal the data from your applications ...


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



Top 50 recent answers are included