Hot answers tagged

6

Utilizing Unicode, it's possible to encode \ and / into multi-byte characters. If the string comparison functions are not unicode-aware, there could be a bug which allows these characters through. Wikipedia has a section on this in relation to an old attack on Windows servers: When Microsoft added Unicode support to their Web server, a new way of ...


4

The error message discloses the full file path structure of this web app, and the versions of Apache, and your OS. That's a lot of info to hand an attacker. The more specifics an attacker has, the more the attacker can custom-tailor their attacks. Best practise is to hide this information, but not to rely on secrecy as a means to protect yourself (security ...


4

On Windows and Unix - no. There may be obscure operating systems that use different path separators. To handle encoding securely there is a simple rule: fully decode before doing sanitisation. If you fail to do this, you sanitisation can be circumvented. Imagine an application that does open(urldecode(normalize(path))). If the path contains ../ then ...


3

As of today (April 5th, 2016) The project was shut down due to lack of contribution, and there is no plan for it to return. As of today, a decision has been made to shut down the Open Sourced Vulnerability Database (OSVDB), and will not return. We are not looking for anyone to offer assistance at this point, and it will not be resurrected in its previous ...


2

If you do the hashing on the server side, the server (and an attacker with access to it) could read your cleartext password, correct. But hashing the password on the client does not really help if someone managed to get access to the server - because the attacker could easily alter the javascript source to get your password in cleartext or start ...


1

You should not only protect yourself from XSS by scanning HTTP requests for attacks. Such a scan will never be complete, and there will always be some smart tricks that slip through the net. Your first line of defence must always be to properly sanitize untrusted data, so as not to create any XSS vulnerabilities in the first place. For how to do that, see ...


1

Let me answer with a few observations, and comments. I will begin with the "whodunit" approach of aiding in determining who, what, when, where, and how. What - a file you found on your system When - what date was it found How - how was it uploaded Who - who uploaded it You already know the file because you found it. Let's call this file: malicious.php. ...


1

Kudos for finding it quickly, it looks like you're doing something right. But you're also doing a lot of things wrong. The most obvious one is that directories within your document root are writeable by the webserver UID. It would help to know what you are trying to achieve by "tracing the origin" of the script. Certainly you should be looking for the ...


1

A few ways. Option 1: A proxy server with authentication. Phone -> proxy (check auth like basic auth if using https proxy, if not https proxy then no real security gain) -> internal-web-server We use these in corporations. You set an automatic proxy file (pac) on your phone to route requests to your domain web page through the proxy and the rest ...


1

As the comment said: IP spoofing is not an option if you want to have a working TCP connection. And you probably need this connection because otherwise the connection attempts will fail at the kernel already and your application will not get any requests. I don't know your application setup but I see the following options: Some applications take a HTTP ...



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