Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment Re:RF? (Score 1) 935

Give me the frequencies. I'll have jammers made in China within a month.

I suspect this is *part* of layered approach to preventing the vast number of unnecessary deaths that occur in the US every year. So this bit *might* be useful in preventing children using improperly secured weapons and inadvertently killing themselves/friends/family.

Whether it's practical or not, I suppose is what the study will establish.

But it's like adding safety features to anything - it likely increases the cost a bit and may result in more product failures... but on the other hand, everyone *may* be safer as a result, and less innocent people die.

Comment Re:Anyone who uses mongodb.... (Score 1) 96

Shard gets corrupted? Oh bad luck, thats some of your data gone - unless you've used also replication in which case you'll have spent 2 months trying to set it all up.

To be fair, I think all exposed MongoDBs mentioned in TFA are being replicated right now, so they've inadvertently got that side of things covered! :D

Comment Relative performance also interesting (Score 2) 39

Ignoring HHVM and just focusing on PHP 7 vs. CMS and Frameworks, the results were:
  1. Laravel 5.1.11 / PHP 7: 1363.24 trans/sec
  2. Drupal 8.0.1 / PHP 7: 917.10 trans/sec
  3. October CMS / PHP 7: 407.89 trans/sec
  4. WordPress 3.4.1 / PHP 7: 306.24 trans/sec
  5. WordPress 4.4 / PHP 7: 287.92 trans/sec
  6. Magneto 2.0 CE / PHP 7: 183.87 trans/sec
  7. PyroCMS v3 b2 / PHP 7: 145.95 trans/sec

I assume Laravel is using static content here hence it's performance, but I'm intrigued at Drupal's performance compared with October and WordPress. Is this because Drupal's sample site is simpler and had less to do, or because Drupal is better optimised/cached?

Comment Use Google Chrome-like extension interface? (Score 1) 44

I seem to recall reading that Edge (like Firefox) will be using the same extension interface as Google Chrome. Obviously, that would make porting existing extensions to Edge rather easy.

Does anyone know if this is still actually the case, or have they, you know, "changed a few things"?

Comment Re:Valid images can contain scripts (Score 2) 74

^ this is really really important!

But it could be even worse depending on your server configuration. I believe (but I haven't tested) that some Apache configurations can result in unknown file extensions being ignored. So if someone uploads a file named say "myhack.php.foobar" and it is placed in a publicly accessible directory, Apache will ignore the "foobar" extension because it doesn't recognise it, and then decide it's a PHP file, and execute it.

Also check out Apache content negotiation (and mod_mime while you're at it) and here the you see that index.html.en and index.en.html could all evaluate as index.html and you can see a similar way file naming could potentially be abused.

The parent post describes how PHP (or any script for that matter) _could_ be injected, but doesn't completely show how it could be executed. The above gives some ideas how that might work.

You _could_ just test that the file name ends with (.png) and Apache _should_ serve it as "image/png". But that's not secure enough for my liking, so my recommendations are:
  • 1. Don't allow users to define their own file names, or if you do, massively restrict the format to alphanumerics and a single dot png|jpg|gif extension.
  • 2. Set the directory where uploaded files are stored to NOT execute any scripts, so even if everything else fails and some how a script gets in there, it still can't be executed
  • 3. Consider not keeping uploaded files in publicly accessible directories. Instead, use a script as a proxy to read those files and serve them with a specific mime type. Thus Apache won't try to execute them and you can be certain what mime-types are being served
  • 4. Be super careful when the file is uploaded that you don't move it into a public directory BEFORE you validate it otherwise there might be a brief window to try to execute it.

And lastly, don't leave anything to chance. This is a really risky area that a lot of people screw up! Never be complacent. Always revisit it. Don't rely on server configuration to be correct because it's too easy to set things up, then move/rebuild a server, and then find you're vulnerable. You need multiple layers of defence.

I have a question to any who anyone who knows - why doesn't Apache demand that PHP scripts have their execute bit set? Because it seems to me that would help quite a bit.

Comment Re:This would have never happened. (Score 1) 128

If the author decided on an open source project, the community could have found and developed a fix during beta testing.

To be fair, the author probably coded it, posted it somewhere, tried it out and then... "oh shit!"
So they likely half-tested it, and it did half work.

Slashdot Top Deals

10.0 times 0.1 is hardly ever 1.0.