Hot answers tagged php
13
You are using a 128-bit key (output of MD5, hence 128 bits) with a block cipher which expects a 256-bit key (Rijndael-256). If PHP was properly implemented, it would blow in your face at that point. However, the documentation states that the key is merely padded with zeros up to the required length. If you use a 128-bit key, you'd better use a cipher with ...
11
Don't bother writing your own site for a practice like that. Instead, make use of the plentiful resources on the web.
A good practice target is the Damn Vulnerable Web Application(DVWA) project. The OWASP WebGoat project is another nice one.
10
In addition to server-side vulnerabilities of all varieties, leaked FTP passwords are also a significant concern. There is a class of client-side infections that harvest your saved FTP passwords from programs like CuteFTP, FileZilla, and DreamWeaver, sending the login credentials to an attacker. This is very common. I've personally seen hundreds, maybe ...
7
I had some fun "decoding" two queries, so here's how I did it in PHP :p
1) or 1=convert(int,(select cast(Char(114)+Char(51)+Char(100)+Char(109)+Char(48)+Char(118)+Char(51)+Char(95)+Char(104)+Char(118)+Char(106)+Char(95)+Char(105)+Char(110)+Char(106)+Char(101)+Char(99)+Char(116)+Char(105)+Char(111)+Char(110) as nvarchar(4000))))--
So let's start with ...
7
The mere fact your DB ran the quoted queries (throwing you the error reports) means you do have injection vulnerability in PHP code. Note, that some methods of inspecting DB tables structure involve running multiple queries with different parameters until DB throws an error and HTML page breaks. That means the failed queries are only tip of iceberg of all ...
6
In order to read PHP code you need a directory traversal vulnerability. file_get_contents() or other file system functions that are exploitable.
SQL Injection under mysql can be used to read source code. For example:
select load_file("/var/www/index.php")
To combat this make sure file_privs are disabled for the MySQL user account used by PHP. If ...
6
The same question had come up in stackoverflow some time back,please find the link below.
http://stackoverflow.com/questions/893959/if-you-use-https-will-your-url-params-will-be-safe-from-sniffing
To summarize the answers mentioned in the link, the url parameters that are sent to the server will be encrypted and hence is not vulnerable to interception, ...
5
Which makes me glad to know that I'm knowledgeable enough in my php to know how to prevent these things.
This is an extraordinarily dangerous mindset to take away from this incident.
That the attacker doesn't appear to have deleted data doesn't mean they didn't read data they shouldn't have. And the fact that they were able to enter inputs that caused ...
5
Sorry to break it to you - you're taking really dangerous chances with those SSNs. Let's quickly define something according to PCI-DSS standards:
Q: What is defined as ‘cardholder data’?
A: Cardholder data is any personally identifiable data associated with a cardholder. This could be an account number, expiration date, name, address, social security ...
5
A few notes
An SQL injection attack is when something unexpected is inserted into a database. The types of injections depend on the vulnerabilities of the system.
SQL Query Injection
If the database doesn't have proper permissions, meaning that the web user has full control over the database, then they can potentially do things like replace all records, ...
4
Recommendations to management need to be framed in terms of effort, costs, and risks. 'Best Practices' and marketing-speak will not communicate well on their own, so defining the problem in terms of effort, costs, and risks will keep everyone focused on the realities of the situation.
Your 'outsider' is not helping the discussion with tossing around a ...
3
There are a lot of things wrong here, but to answer your question; no, there is no problem with calling serialize(); on user-submitted data. The only problem is what you then do with the output.
Your entropy gathering essentially boils down to: microtime() which will give you about 12 bits of entropy given typical TCP latency noise to a remote server, ...
3
One tiny addition to comprehensive post of D.M.
CSS2+ can also manipulate text on the page. See MDN for content CSS property details and this for examples.
Compare this behaviour to expression() javascriptlets in IE6 CSS: in both cases CSS is performing smth more than just styling... Pity, this is a part of CSS standard.
2
It appears that the attacker was trying to do some investigation into what sort of attacks were possible with the vulnerability he had found.
Regardless; the lesson is always the same: use parameterized queries. If you have to remember to quote and escape your data, then you're doing it wrong.
If you'd like to learn more about how typical SQL injection ...
2
There are two possible ways that an attacker would be able to read this file as text, rather than execute it.
If your web server is misconfigured, then the php might not be executed. You obviously need to have php installed and running server-side, as well as have a web server in place that supports this. If, for some reason, something goes wrong with your ...
2
The difficulty with these sort of code injections is that if you are using a hosted service provider is it possible for the infections to spread between the various clients hosted. It may not be your actual installation of WordPress that is the problem.
Another thing you can ensure is that all of your plugins and your WP is up to date. Following the ...
2
I don't see any resemblance of access control in either scenario. If you haven't been told this already: stop using md5! it is old, broken, and inefficient, use SHA-256 or just a simple cryptographic nonce.
In the first scenario if the attacker knows this magical "md5hash" then they will be able to always use this edit feature. How do you keep the user ...
2
If your attack model allows "attackers to upload their own scripts", then they have access to everything those same script can see or do, and "secure access to database", for this value of secure, is simply not possible.
(Short of redesigning the database so that it can run a check on all PHP files involved in a given connection - while theoretically ...
1
To add to Terry Chia's resources, there's an SQL injection tutorial from PentesterLab which does pretty much what you're after, called From SQLi to Shell. I did it yesterday, it's very good. They offer a couple more advanced walk-throughs too.
1
Any form that takes input and uses it directly in a SQL query without checking to make sure the input is safe would be vulnerable to SQL injection. Being vulnerable to SQL injection is more or less the standard state of being unless you specifically take measures to protect against it in your code.
1
You could make an internal website only accessible to localhost that would pass the credentials to the main PHP script and thus the file would be inaccessible to the main site's user context and would only be stored in memory, but that's probably overkill for most purposes.
If you put the configuration in a file that isn't accessible directly from the web ...
1
You are implying security by obscurity. That is this is a large random number that could not easily be guessed, and might take some time to brute force through. However, since you are hashing a value, the md5 value becomes more predictable - maybe tied to some known variables. Increased randomness is better, but it misses the point.
These types of values ...
Only top voted, non community-wiki answers of a minimum length are eligible
