New answers tagged

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 ...


4

The short answer No. This is not safe, and should not be done. In fact, this is the last one of OWASP Top 10: A10. Unvalidated Redirects and Forwards Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims ...


2

To add to what others have said : If you have a set of known URL's to redirect to (that you could map to an identifier), it would be much better to allow only known identifiers in the "redirect" parameter value. Then you can map the identifier to your safe, known, URL. Thanks to such a technique "all your troubles" go away. Of course if the value of ...


3

Current versions of PHP detect and prevent newline injections in the header function, see How to avoid HTTP Header Injection (new lines characters). In older versions pf PHP you could probably do something like login.php?redirect=%0D%0A%0D%0A<script>... Which would break out of the header and result in Location: <script>... And your ...


1

The first vulnerability I can think of is to pass a full URL as an argument that will redirect the user to a fake copy of the site (login.php?redirect=http://malicious.com) Aside from that, I'm sure there are several ways to prevent the redirection from happening and displaying instead malicious HTML/JavaScript. As a general rule, any URL parameter should ...


0

There are a few free static analysis tools for PHP, take a look at this OWASP link for more details. RIPS is now abandoned, but according to their sourceforge page, a new version is in the works... DevBug is an online tool, but its reporting is basic. Static analysis won't find every possible bug, it should be used as part of a more complete testing ...


0

First of all, remember that in most countries (if not all) accessing protected Wi-Fi networks without authorization is illegal. There are techniques you can use to do this, but I'm not going to describe them because it seems that you might use them to break the law, even if not knowingly. Learning ethical hacking is great, but you need to keep it ethical and ...


2

This looks like your run of the mill script-kiddie backdoor PHP script. The attacker likely has very little experience as they've just downloaded it from another site, they didn't even write it themselves. All they did was update some configuration. Well, the IP address is an IPv6 address, which relatively few people are using. Looks like it's likely ...


2

I will focus on the second part of the question: and prevent future attacks? Basically, what can you do in order to prevent from future attacks is: keep your Wordpress up to date consider using automatic updates, by adding this peace of code in wp-config.php add_filter( 'auto_update_plugin', '__return_true' ); or automatic update for all themes: ...


0

One of the most important laws of security: Never ever think about trusting the client. No exceptions. If your client can send any file for you and have direct access to it later, you are asking for trouble. If your files are pictures, make sure they are really pictures. Searching for .png on the extension or Content-type: image/png is not enough. You must ...


4

It would be easy to sniff data using tools like WireShark from someone who can access the data path between your client and the server. This isn't something anyone on the Internet could do per se but if your device uses wireless and there are people nearby they could grab this data if they wanted it. As for finding your UDP service on-line that is easy to ...


2

Minor ranting This is a bit broad, and there may be some that are unknown at present, but there's usually good references out there if you're willing to search for them. Code execution isn't the only problem. You want to be careful of things that can lead to code execution. However, and as always, it's important to study these functions to see what ...


1

It seems that someone is using this exploit: ProFTPd 1.3.5 - File Copy https://www.exploit-db.com/exploits/36742/ Here is also CVE-2015-3306: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3306 Check your proftpd version proftpd -v, if it's still old version then update to 1.3.6rc1. If you want something better, then consider to use sftp and ...


2

Generally speaking, any combination of bytes you might send into hash_hmac in the $data parameter will be correctly processed by the function, so no sanitation is needed at that point in your script. However, you'll probably still need to do sanitation at some point in your script, but by checking the mac up front, you'll prevent all those wasted CPU cycles ...


0

What is someone edits the JS and sends different values to the external payment processor? Is that possible? And if it is, how to I securely make sure this does not happen? It's possible. Here is a way that PayPal handles it: Payment button code is encrypted before it is displayed on the merchant website. You could do the same or use a shopping-cart ...


2

The user's client should submit only the order's list of items (and quantities) to the server. Anything else about the order -- especially how much the entire order costs -- should be computed on the server, based on the list of items that were ordered. If the user mucks around with the JavaScript that submits which items the user has ordered, there's ...


5

Should I escape input when using prepared statements? No. You really don't need to escape input if you use prepared statements. If you want an additional layer of security, use some kind of input filter (eg get me only integers, get me only valid emails, get me only alphanum, etc). And you obviously should not escape your password, as it doesn't even go ...


6

Is this SQL injection? Yes. Why? Let's look at what's happening here. $query = "SELECT pass FROM social WHERE email = '$id'"; This passes $id directly to the query. If $id is not sanitized, SQL injection will occur. if($_POST && isset($_POST['submit'], $_POST['password'], $_POST['id'])) { $pass = ($_POST["password"]); $id ...



Top 50 recent answers are included