Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment PHP is to blame (Score 2, Informative) 100

It appears that PHP, upon seeing an incoming parameter with a name that ends in [something] (where something may be empty), automatically turns that variable into an array.

How many of you PHP developers out there knew that? I didn't. And I had to dig quite a bit to find a reference to this behaviour in the docs.

So, incoming stuff from the URL or the POST data are no longer strings all the time. Can they magically become other things than strings and arrays as well? Maybe not now, but what if some PHP developer thinks up another "nifty" feature _after_ I read the docs; how then am I supposed to protect my application in the future? Do I need to re-read the docs every time I upgrade PHP?

And is there a way to turn this "we know better than you what you need"-behaviour off?

I'm sick of seing framework developers add "nifty" features that you have to know about in order to write secure code. It's not only PHP, but also several highly popular Java frameworks that I work with these days. Some of them make it quite easy to write to object fields that are normally out of reach of the input fields in a form.

I want a framework that makes it impossible to make mistakes, and where you have to _enable_ potentially dangerous features when you _know_ you need them, rather than _disable_ potentially dangerous features most people don't know about (or use).

Comment Re:I Only Use Slashdot Anyway (Score 2, Interesting) 398

I don't know about the new attacks, but I researched a bit after
Gregory Steuck posted about "XXE (Xml eXternal Entity) attack" on
Bugtraq in 2002 (http://www.securityfocus.com/archive/1/297714).

You can easily do DoS attacks on a Java-based thing running on
e.g. Linux if you manage to trick the server into parsing one of the
following two XML documents:

        <?xml version="1.0" encoding="ISO-8859-1"?>
        <!DOCTYPE foo [
            <!ENTITY xee SYSTEM "file:/dev/tty">
        <foo>foo: &xee;</foo>

        <?xml version="1.0"?>
        <!DOCTYPE foo SYSTEM "file:/dev/tty">

Both will make the XML parser try to read from the TTY, thus blocking
"forever" waiting for input that never comes. The fun thing is that
it doesn't help to setExpandEntityReferences(false), even though the
name sounds like it would help. The only thing that works (afaik), is
to install a custom made EntityResolver that refuses to look up
external entities. Since nobody does that, this vulnerability may be
found all over the place.

Variations exist for other OS-es and other web platforms as well. I
even found that Adobe Reader was vulnerable once
(http://shh.thathost.com/secadv/adobexxe/), and I recently stumbled
across a similar thing in a commercial web-protecting security
application. (They're working on a fix.)

Comment Microsoft's history of anticompetitive behaviour (Score 4, Informative) 461

Since the article mentions Microsoft's attempts to undermine competing businesses, here's an interesting link to the Eupean Committee for Interoperable Systems' (ECIS) article "Microsoft: A History of Anticompetitive Behavior and Consumer Harm" (PDF): http://www.ecis.eu/documents/Finalversion_Consumerchoicepaper.pdf Published on 2009-03-31. Required reading. :-)

Comment Astronomical? (Score 2, Interesting) 410

Astronomical? Like in millions of millions of stars?

If you compare to Oslo, the capitol of Norway, the closes neighbour to Sweden, the four guys have been sentenced to pay the price of a big house each (that is: four houses in total, in case I get the wording wrong) in the second most expensive part of the city. It's a lot of money (a lot!), but hardly astronomical.

Slashdot Top Deals

The trouble with opportunity is that it always comes disguised as hard work. -- Herbert V. Prochnow