New answers tagged http
0
The main advantage of accessing the proxy with TLS is that somebody who can sniff the traffic between the client and the proxy cannot see sensitive or private data. This means of course the domain the client is accessing (i.e. endpoint of the requested tunnel) but also any credentials used for proxy authentication.
Additionally TLS might also protect the ...
0
I don't think this is exploitable.
If you want your server to allow any origin (this might not be the safest setup, but anyways), a common way to do that is to simply echo back whatever the client sends as Origin in Access-Control-Allow-Origin. I guess that is what is happening here.
How are you setting two origins? I assume that it is not the browser that ...
0
Protecting against enumerating valid session cookies is easy: just make the search space too large for an attacker to have any hope of finding another valid value this century. For example, if the cookies are cryptographically secure [pseudo-]random 128-bit values, there could be a billion (~2^30) unique active sessions at once (that never expire) and you ...
0
First of all, to be clear: A site that returns ACAO: {your origin} for arbitrary origins, and also returns ACAC: true, is completely insecure. That site has, for the most part, turned off the same-origin policy's protections for itself; any other site on the Internet is able to view the content of, and take control of, any user's session on the vulnerable ...
1
It depends on the header, and on what the library is designed to handle. Let me go through each header and explain if it would make sense or not:
Does specifying Content-Type make sense?
Yes and no. It's certainly nice for the server to tell us that the response is in JSON, but it is by no means a requirement. It would make sense to throw an exception if ...
0
The entire 127.0.0.0/8 address range is localhost so you can block outgoing traffic for one address in this range for example 127.1.1.1.
Then use the hosts file to redirect unwanted traffic to this address so unwanted tracking requests won't hammer your webserver running on localhost.
1
Here are some disadvantages of using self-signed certs in your scenario:
Some clients out of the box will not work with self-signed certs. You may have to tweak your code to get them working, though this is usually a one-and-done type of tweak.
In order to thwart a MITM attack you would need to make sure that only these specific certs are allowed (which you ...
0
Using self-signed certificates is always dangerous if you don't pin the certificate based on its fingerprint. Third-party certificates are probably better for your scenario. A third options would be creating your own internal CA as Sean E. M. suggested. However setting up and maintaining an internal CA is not a trivial task.
1
A third option might be to consider using an internal CA that you trust.
Remember, signing a certificate is a method of vouching for the authenticity of the host using it. A Defense-in-depth approach would dictate that self-signing not be used, particularly for microservices that might be processing production information. Self-signed essentially means the ...
0
The "\r\n\r\n" words. It's like the image, it's interpreted, not written
3
Technically, it is entirely possible for a web server to return different content depending on whether you accessed it via HTTP or HTTPS. In fact, nearly all servers supporting HTTPS do this; if you access /foo/bar via HTTP, you get a redirect to HTTPS, and if you access it via HTTPS, you get page content (or at least a 404). It's rare (though not unheard-of)...
1
Hopefully , it will be very hard to insert clearly malicious code into a CDN.
Is CDN code highly likely not to be malicious? Yes
Should you the CDN domains be whitelisted for an ecommerce ? No (*)
It is possible that a CDN can be compromised. They have in the past (and there are many kinds of CDN, and each will have their own security practices), but I ...
1
What is the likelihood that a malicious actor could get their own malicious code added to one of these CDNs?
I would say this is unlikely, and there is are easier ways to exploit XSS when CDNs are whitelisted.
The more dangerous thing is that CDN's host JavaScript libraries such as Angular, that perform JavaScript actions based on HTML code. So an attacker ...
2
If you want to replay the exact request you have in the file as plain HTTP you can simply use netcat:
cat request.txt | nc host 80
If you want to replay it as HTTPS instead of HTTP you can use openssl s_client:
cat request.txt | openssl s_client -connect host:443 -servername host
1
curl is the tool for the job. You can view the documentation here as to how to pass all of the headers in the POST request that you have listed in your question. You'll want to use the -H option to pass the header parameters that you show.
If the request is initiated from Firefox or Chrome, you can follow these instructions to capture a curl command ...
2
I figured out the issue. The problem was not with the CA key, it was with the private key. Once i remade the private key using this:
keytool -genkey -alias gis.akrf.com -keyalg RSA -keystore "C:\Program Files\Apache Software Foundation\Tomcat 9.0\conf\Keystore\keystore" -ext SAN=dns:(your dns here, like some.domain.com or localhost, which should also ...
0
You have the keystore and the truststore. The truststore is where you store CA's you trust, the issuer CA must be added to the truststore. The keystore is where you store the key. Does your keystore contain both private key and the certificate? Your connector must point to both the keystore and the truststore. If you are working on the same Tomcat server you ...
1
I'm not 100% sure on this so please correct me swiftly if I'm mistaken.
I think the main confusion here is that the Django docs are specifically talking about a CSRF cookie. CSRF is when someone triggers your user's browser to make a request to your server, and their browser automatically sends your server's cookies along with the request. What you don't ...
0
If you consider that the network between the VPN's endpoint and the OAuth2 server is safe (because request are reencrypted, or it's a "trusted network"), then an HTTPS tunnel or a VPN tunnel offers the same level of security (encryption and authentication).
However, as stated in section 3.1.2.1 of the OAuth2 RFC:
The redirection endpoint SHOULD require ...
5
The first point to observe is that if you click one of the above addresses you shouldn't be able to open it. They all point (clearly in the case of Azure) to a link-local IP address. These are reserved addresses in the space 169.254.0.0/16 that are not forwarded by routers, and crucially are only accessible from a given instance.
The second point to note ...
Top 50 recent answers are included
