New answers tagged

2

In addition to what the other answers mention, there's one more attack risk. Someone can deny you updates for a period. While they can't forge packages and package lists, they can substitute them with previous, signed, versions, thus making your system believe that there's no new upgrades. How apt-secure works is well outlined in this document from Debian. ...


0

TLS, which is the encrypted tunnel used for HTTPS, provides three things: privacy (others cannot see the data transferred), integrity (others cannot modify or delete the data transferred), and authenticity (others cannot impersonate the remote machine). Most APT repositories use a set of nested hashes (functionally equivalent to a Merkle tree) and digital ...


5

apt (and other package managers) uses digital signatures to verify the authenticity of packages after downloading them. If a MITM modifies a package in transit, you get an error since the check fails. See https://help.ubuntu.com/community/SecureApt Apt-get package management uses public key cryptography to authenticate downloaded packages. Using HTTPS ...


0

Document-Poicy is for more performance/best-practice options. Permissions-Policy is for handling "powerful" features that you don't want third-parties or new devs using.


1

Is there any possibility that an attacker can grab the data, or maybe the data could be stored anywhere between my PC and the company's server? Yes, there are many ways that an attacker can eavesdrop on an https connection between you and a server. For example, if the server's private key is compromised, then an attacker that is able to position himself ...


1

No system is 100% secure. But encryption provides a high level of security for data in motion. But it doesn't mean that your data is 100% secured or impossible to break. Especially you may be trying to access a phishing website. Even though HTTPS is secure, you are sending data to a malicious website. In addition, the certificate key may be compromised but ...


0

HTTP plitting is not the simplier attack. The target is not your browser, sometimes you could use CRLR injection to target the browser (like injection of Location: header) but really the whole domain of HTTP smuggling is not about targeting the attacker browser. When a single HTTP request generates 2 or more HTTP responses and the communication occurs just ...


2

The fact alone that a site returns large amount of data does not mean a DOS. Many sites do this, like all the download and video portals. Don't confuse this with amplification attacks just because a small question leads to a large response. Amplification attacks are about directing this large response to some victim, which is not possible here, i.e. the ...


1

My C++ application sends HTTPS POST and GET requests to a third party website. In these requests it sends a private key, which shouldn't be known by anyone except my application and the website. So can user use some kind of software, like firewall app etc. and see this private key? Yes. Stealing the data out of HTTP and HTTPS GET/POST requests from a native ...


0

Immediately after server B receives a request from server A (and before responding to the request), server B can initiate an HTTPS connection back to server A (based on the IP address that the the initial request from server A originated from). Assuming the SSL/TLS handshake is completed successfully, this will result in: server B receiving server A's ...


0

What you are talking about is called authentication: A needs to prove that it is really A. One of authentication methods can be authentication based on client certificate (when A want to use some service of B, the we say that A is a client of B). Another method, much simpler, can be usual User/password authentication. The services that B provides should ...


0

Check what log is it. If this is a log before the TLS termination point, then the server does not see the URL and paramaters, because they are encrypted. If the log is behind the TLS termination point, then the server can of course see the whole request. Use HTTP POST instead of HTTP GET. Put user name and password to the request, don't use them as request ...


0

Not really. The cost of a 302 Redirect should be negligible. Moreover, most browsers detect an infinite loop at the second or third iteration (if no cookies are involved, then at the second). So you're getting double or triple load for that one endpoint; it's no great mischief. If this is caused by a bug such as a wrong .htaccess rewrite rule, so that all ...


1

This may be a real problem. By definition the HTTP response Headers are usually trusted. In a context with some reverse proxy caches between you (the browser) and the 'faulty' server you may be able to do bad things on the reverse proxy caches (or http load balancers, ssl terminators, etc.). You may be able to generate cookies from this server with GET ...


4

Yes. The user could decompile your program, add some code that writes the parameters into a file, then compile it again and run it.


4

HTTPS protects against man in the middle attackes. Machines between the client and the server can not see HTTP GET or POST parameters. However, other applications on the client (e.g. a TLS intercepting proxy) could potentially read the entire request, parameters included, in clear text. Or an application with sufficient priveliges could read the secret key ...


1

There were times that this would be a reason to investigate (20-25 years ago). At some point in time, it became so common that I put up a static page with insults at http://<my ip address>/phpmyadmin. Now, it is just something you need to learn to live with. These are more or less standard attacks for badly configured (or still default configured) ...


0

IPS seems not to work without a bridge, right? Here is a docker setup that may work. This is my iptables entry: 111 5788 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8081 to:172.20.238.3:8080


Top 50 recent answers are included