Oh, I see. Anyone who disagrees with you is either a malware maker, a webmaster that relies on annoying ads, or a fool.
And you're accusing me of ad hominem attacks. That's rich.
Anyway, you're using hosts files for something they're completely unsuited for, and you're arguing in favour of violating the TCP/IP spec to suit your incompatible use case.
I'm unsurprised that Microsoft ignored you, and frankly were I in their place I'd do the same.
In an effort to make the IE a critical part of Windows, all sorts of components of Windows (like the help system) have been shoehorned into IE.
Wrong, wrong wrong. Trident is the component that renders HTML content (like HTML help) and that's as integrated into the system as KHTML is to KDE, and WebKit is to Mac OS X. I'm so sick of hearing bullshit like that spouted all over the place.
No, even Microsoft training doesn't spit out people that stupid. Bear in mind, MCSEs are trained to set up servers, not set up Firewalls. And if the people you deal with don't know what an FQDN is (one of the core important concepts of AD), then they aren't qualified.
Your experience is not typical for properly trained MS admins either. Shitty admins can make any OS shitty. Stop blaming Windows.
Sorry erroneous, it appears that it is an option for MySQL client libraries. Not server side, and some MySQL client libraries don't implement the "default block multi-statements" behaviour.
That's not a MySQL setting, that's a client library setting. So, like everyone's been telling you, the client is responsible for preventing bad stuff happing, not the server.
Interestingly, whoever wrote the MySQL/Net client library did leave support for it in.
And besides, it's still your fault if software you write gets hit with an SQL injection. Use parameters, it's what they're for.
No, it is most assuredly not disabled by default, or even a setting you can disable. As mentioned though, I think many versions of the PHP MySQL extension prevent it themselves - but MySQL certainly isn't responsible for that.
There are two separate inquiries going on. One about their restriction on programming language you can develop for iPhone in (apparently there is a chance that could be called tying) and another related to their advertising rules.
And discussion also spells out why this wouldn't likely happen in a LAMP scenario -- no multiple query commands by default.
This statement is not entirely true. If you see MySQL and PostgreSQL documentation you'll see that both support the same sort of technique. Different frameworks may try mitigate (some versions of PHP may take a dim view to multiple statements in a single query for MySQL as an example, but the PHP docs for Postgre say that PgSQL will in fact run every statement you include in your query).
Other databases (notably Oracle) that support multiple statement execution require you to wrap the whole thing in "begin"/"end" blocks so they are not vulnerable to the particularly severe form of this attack that SQL Server is vulnerable to. That is why if an SQL injection attack is in the news, it is inevitably an attack on a poorly written MS SQL application.
Neither MySQL nor PostgreSQL do.
And in fact most SQL injection is reported on badly written PHP applications - presumably since noone could be bothered writing something as gigantic as this SQL injection code. Shitty code is shitty code in any language.
Slashdot Mirror
Four patents.
Gandi SAS is not in the USA. It was registered in France, or wherever they are.
Oh, I see. Anyone who disagrees with you is either a malware maker, a webmaster that relies on annoying ads, or a fool.
And you're accusing me of ad hominem attacks. That's rich.
Anyway, you're using hosts files for something they're completely unsuited for, and you're arguing in favour of violating the TCP/IP spec to suit your incompatible use case.
I'm unsurprised that Microsoft ignored you, and frankly were I in their place I'd do the same.
Please don't encourage APK. He posts his hosts file bullshit in every Windows thread in existence.
Servers aren't vulnerable to Help and Support exploits. Microsoft ships Windows Server with the required services disabled.
In an effort to make the IE a critical part of Windows, all sorts of components of Windows (like the help system) have been shoehorned into IE.
Wrong, wrong wrong. Trident is the component that renders HTML content (like HTML help) and that's as integrated into the system as KHTML is to KDE, and WebKit is to Mac OS X. I'm so sick of hearing bullshit like that spouted all over the place.
No, even Microsoft training doesn't spit out people that stupid. Bear in mind, MCSEs are trained to set up servers, not set up Firewalls. And if the people you deal with don't know what an FQDN is (one of the core important concepts of AD), then they aren't qualified.
Your experience is not typical for properly trained MS admins either. Shitty admins can make any OS shitty. Stop blaming Windows.
It is indeed.
Unlikely. In our neck of the world (South Pacific), there are no official Apple stores, so Apple needs all the resellers they can get.
Yeah, but our government does it deliberately.
As an importer, I have one thing to say to them: fuckers.
You only wish the ACCC would hammer Telstra like the Commerce Commission here in New Zealand hammers Telecom.
And you should see the shit the get into in New Zealand.
They've gained themselves quite some derogatory names and slogans.
"JB Lo-Pay"
"Always lowest wages"
I know someone who works there, and they apparently make Dick Smith look angelically ethical by comparison.
Sorry erroneous, it appears that it is an option for MySQL client libraries. Not server side, and some MySQL client libraries don't implement the "default block multi-statements" behaviour.
Stop calling it a vulnerability. It's called the batch syntax, and it's supported by every RDBMS in existence.
The vulnerability is shitty client code not sanitizing inputs.
That's not a MySQL setting, that's a client library setting. So, like everyone's been telling you, the client is responsible for preventing bad stuff happing, not the server.
Interestingly, whoever wrote the MySQL/Net client library did leave support for it in.
And besides, it's still your fault if software you write gets hit with an SQL injection. Use parameters, it's what they're for.
No, it is most assuredly not disabled by default, or even a setting you can disable. As mentioned though, I think many versions of the PHP MySQL extension prevent it themselves - but MySQL certainly isn't responsible for that.
They can't do that. The uninstall button being disabled is a design decision by Mozilla. Go bitch to them about it.
Informative? What the fuck?
Since when has bullshit conspiracy theory been informative?
There are two separate inquiries going on. One about their restriction on programming language you can develop for iPhone in (apparently there is a chance that could be called tying) and another related to their advertising rules.
I don't know, Basecamp seems like a pretty good example of Ruby actually working.
But then, you'd hope the people who developed Rails could actually use it correctly.
Your retraction post is incorrect.
And discussion also spells out why this wouldn't likely happen in a LAMP scenario -- no multiple query commands by default.
This statement is not entirely true. If you see MySQL and PostgreSQL documentation you'll see that both support the same sort of technique. Different frameworks may try mitigate (some versions of PHP may take a dim view to multiple statements in a single query for MySQL as an example, but the PHP docs for Postgre say that PgSQL will in fact run every statement you include in your query).
Urchin doesn't support SQL server. I run Urchin and it works with either Postgre or MySQL from what I see.
Really? I didn't realise that MySQL and PostgreSQL weren't databases!
Other databases (notably Oracle) that support multiple statement execution require you to wrap the whole thing in "begin"/"end" blocks so they are not vulnerable to the particularly severe form of this attack that SQL Server is vulnerable to. That is why if an SQL injection attack is in the news, it is inevitably an attack on a poorly written MS SQL application.
Neither MySQL nor PostgreSQL do.
And in fact most SQL injection is reported on badly written PHP applications - presumably since noone could be bothered writing something as gigantic as this SQL injection code. Shitty code is shitty code in any language.