Tag Info

Hot answers tagged

25

End users should just wait until their sysadmins contact them with further instructions. At some point, after your sysadmins have patched vulnerable systems, you may have to: Change passwords Login again (because all session keys and cookies need to be invalidated) Help senior management evaluate the actual content handled by the vulnerable servers that ...


3

If the user invokes over x amount of queries per x amount of time which seems impossible via a human then you'll want to generate a captcha to prevent bots. If the user invokes a silly amount of requests just ban his/her IP for x amount of time as it's clear they are using some form of botting. You could generate a key everytime the user searches (This ...


2

As Paul mentioned, using a key will prevent basic bots to crawl your website, but more advanced scripts will bypass that easily. Also note that modern bots are capable of running Javascript as a real user would do, and that includes Google Analytics JS code. A reasonable balance in terms of security versus user-experience, would be to configure quotas and ...


2

Since I use php as an Apache module instead of CGI, and the http code was 404, I think nothing bad happened, right? right What was the attacker trying to do (or, if he was successful, what did he do) to my system? it was probably the first stage in a multi-stage-attacke(script); this is just the first scan, if you system is vulnerable or not.


1

I like keeping this simple. If the webserver runs OpenSSL 1.0.1 through 1.0.1f and accepts SSL connections, it will most likely be vulnerable. As Steven says, this is SSL/TLS protocol wich is transport layer security. This exploit is not on the application layer of the OSI layer. Have a look at heartbleed.com for detailed information about the exploit.



Only top voted, non community-wiki answers of a minimum length are eligible