New answers tagged attacks
0
To expand on one point from Steffan's answer: whenever you have code that is consuming untrusted input and considered an exploitation risk - such as an image library consuming files from untrusted sources - you should look at sandboxing that code. There are a number of ways to do this, varying by things like language, OS, and CPU architecture, but here are ...
1
There are a couple of obvious things which are not limited to image parsing libraries:
Don't assume that the input is well-formed but actually check it. It is actually a common problem with image or video libraries that they were not designed with deliberately malformed input in mind but which are nevertheless used to process input from dubious origins.
Use ...
4
I recently read Hackers can use a WhatsApp flaw in the way it handles video to take control of your phone, so theoretically it is possible via PDF as well, depending on your OS and possible flaws in WhatsApp and your phone’s OS.
7
This is not a cross-site script (XSS) attack. This is you editing the page inside your own browser to attack yourself. You can try to write down and publish the necessary instructions how each victim can attack itself but this is not cross-site and not even a real attack. This is more like telling someone how he can shoot himself.
1
I may do this in a security audit if something smells fishy, and I have done so for both reasons you mentioned:
Denial of Service: I've seen systems that, after too many requests, just bugged out by having too many file handles open. I guess a session system would be even more vulnerable, since it might have on-disk files that it's keeping open. Or just ...
2
On the security side, you can protect yourself with:
Rate limiting tools like fail2ban to block DDoS and other automated noise
Recaptcha to block brute force attempts
A stateful firewall, intrusion detection, or intrusion prevent appliance to block known attack methods
(This site forbids product recommendations, but there are packaged/supported paid ...
0
The protocol does not mention any random padding, which means that E(P,m) is a deterministic function. It means that, given the same public key P and message m, the result of E(P,m) is always identical.
If the attacker C can sniff E(PA, m) and E(PB, m), then they can try all possible values for m, and see which m results in the same encrypted message.
The ...
Top 50 recent answers are included
