You would likely need something you could smoke or vaporize, or at least easily cook into/dissolve in fat, because I don't *think* enough cannabinoids would be released for a person to feel the effects, otherwise.
To add to that, I guess magic_quotes_gpc is deprecated in PHP 5.x anyway, so you're right that it's not worth using. But there are settings within php.ini that can help harden PHP, though as I've said, it's absolutely no substitute for well-written code.
You got me before my morning (afternoon) coffee so here are some haphazard thoughts:
1) You're writing a PHP/MySQL app. It doesn't matter if it's a game or the next big social networking site. There are holes common to all web apps (check out the OWASP Top 10). There are also holes common in PHP code, such as remote file inclusion. There are things you can do wrong with JavaScript. Learn about them, learn about how to prevent them and write your code accordingly. Security should be part of development, not something you tack on afterward. This means using good coding convention (i.e using parametrized queries instead of concatenation, always encoding output, etc) and ensuring that any design decision you make does not compromise the security of your application. Make sure security is multi-layered as well. For example, even if you think your app is 100% free of SQL injection (wrong assumption!), you still need to make sure you've properly hashed user passwords in the database in case they're exposed. (Side note: please don't use MD5 for this; look into bcrypt, or at least many rounds of SHA-256 or such.)
2) Harden your environment. No amount of hardening will stop all attacks, but it may help mitigate their impact, and if you're lucky, it may thwart some script kiddies or automated scripts. Running PHP? Harden the crap out of your php.ini (magic_quotes_gpc, turn off fopen() for URLs, etc). Think about installing the Suhosin patch. Just don't get complacent; there are ways around all these protections and they are not a substitute for secure code! You may also consider a web-app firewall (WAF), in the vein of mod_security, but don't fully rely on these either. If you're publishing code for others to use, don't ever count on your users to implement these same protections in their environment.
3) Web app scanners can help, especially if you're a novice with security, but once again, they will not catch everything (probably not even a lot of things.) There's skipfish, NetSparker and free versions of some of the more commercial scanners.
4) I know your question was whether to publish your code. I say "Yes", but this is a personal opinion -- I just happen to think it will give security dudes more of a chance to audit your code, and attackers will find your vulnerabilities anyway, through poking at your app and fuzzing even if nothing is published.
Who are these "common people" you're talking about? At least you give them credit for knowing what the Internet is. But since they've, ostensibly, been on the Internet before, why do you think a Photoshop on a government site would somehow make them revolt against their government?
When you say "local sheriff", it makes it sound like he's the sheriff of some small town. In fact, Tom Dart is the sheriff of Cook County, which contains Chicago, is the second most populous county in the U.S, and his department is the second largest in the U.S.
People claiming Dart is drumming up publicity are pretty much correct. Keep in mind, we're talking Chicago here, so consider the history of the political machine here. Dart also refused to evict renters from houses when their landlords lost the mortgage. In a way, this is an honorable thing to do, but the way it played out, everyone read it as once again more publicity for Dart. The Craigslist case just further proves his motives.
Does anyone else worry about sending sensitive information over a service like Twitter, which has had security issues in the past? And, assuming this works over DMs, what if a user instead accidentally uses a reply or just a straight Twitter post? What sort of information have they just inadvertently exposed?
Aside from the usual gripes about the efficacy of pen-testing, this gives pen-testing a bad name. The firm I work for does this exact same ploy, and so do teams from the Big 4 and various security firms, but they are always planned ahead of time. You have to do this sort of thing in a controlled manner (or as controlled as possible.) Usually, these things are dropped in a parking lot, the the payload is innocous, because a customer (or member in the case of a CU) can pick it up. These guys exposed themselves to a lot of liability and can screw it up for honest hardworking sellout hackers such myself and others.
So, sex offenders aren't allowed to use LinkedIn, but they're allowed to use AIM, Yahoo and chat rooms? Interesting approach; this is what happens when the government tries to regulate something they know nothing about, and take the easy approach of using overarching, way-too-generalized statements.
Did you bother even reading the article? The code is in httpd.c, which obviously handled both types of connections. I almost hate SSL sometimes because people equate it with security -- but not encryption or integrity, but that somehow it's a magical fix-all for whatever the security flaw is. I see this kind of thinking in IT people in charge of the enterprise and it scares me. Security is not about having a setting enabled, and it certainly requires much more analysis than a simple dismissive suggestion.
But there have been many browser exploits recently, and they've been in virtually every component of the browser. This flaw has nothing to do with JavaScript itself, just the implementation. Flaws have been found in XML and HTML rendering engines, third-party components, URL handlers and many other pieces of the browser. If we're going to disable every feature that's potentially vulnerable, we might as well stay off the Web.
In my humble and largely anecdotal experience, Postini works well. We send out e-mail that can often be flagged as SPAM when we perform penetration testing, and Postini seems to be the toughest to get around. We see in-house devices such as IronMain, and outsourced services such as MXLogic and FrontBridge/hosted Exchange, but Postini seems to do the best at stopping illegitimate messages. The company I work for uses this it as well, and logging into my Postini inbox I see a lot of spam but no false positives. I think it's a pretty good solution if you don't want to handle SPAM in-house.
They run XP embedded, which allow you to customize which components are used much more so than regular XP. That is not to say I don't see your point -- we've broken into plenty of Diebold XP ATMs during authorized penetration tests using regular Windows exploits. After that, it's game over with the software this product mentions. Then again, regular OS's have been running on ATMs for a long time, and many still run OS/2.
Though I haven't had a chance to evaluate it just yet, I think this is a step in the right direction. Flash security is often overlooked, while Flash itself is often overused by designers who think that pretty effects make the web page. It gets especially bad when Flash is used for activities that require some sort of security, such as a login form. 99% of the time, instead of POST'ing that information to a server side script, it's handled inside the SWF file. Since these can be easily decompiled (grab a copy of Flare or any other decompiler), the password is easily revealed. I recently found a network product which went through the trouble of XOR'ing a password and storing in a text file. Two problems: the text file was in the web root, and the XOR key was inside the SWF. Tools like this can only raise awareness of these types of issues.
I don't know about it nearly crashing the Internet. How many people actually noticed a difference that day, for that matter?
A lot of admins, especially after the alert went out over the NANOG list, set their routers to reject long ASPATHs (or I assume, from what I saw on those list, I am not a BGP admin myself.) Many routers simply rejected these ASPATHs as well; correct me if I'm wrong, but weren't old versions of IOS the only ones affected? It was a serious issue, but I'm not sure if it came anywhere near a disaster scenario.
Closed source applications have to be audited with fuzz testing and other techniques, and this means that bugs can hide from the "white hats" (or the company) for a long time. Look at the bug fixed by MS08-067; it was discovered in the wild as part of a trojan and is now at the center of one of the biggest worm breakouts in history. Open source software can be fully audited by third-parties, including through techniques such as static analysis. I am not anti-closed source per se, but calling it somehow more secure because it "can't be verified" is the opposite of the truth. Tell your customers to talk to a security professional, not a salesman.
Slashdot Mirror
You would likely need something you could smoke or vaporize, or at least easily cook into/dissolve in fat, because I don't *think* enough cannabinoids would be released for a person to feel the effects, otherwise.
To add to that, I guess magic_quotes_gpc is deprecated in PHP 5.x anyway, so you're right that it's not worth using. But there are settings within php.ini that can help harden PHP, though as I've said, it's absolutely no substitute for well-written code.
You got me before my morning (afternoon) coffee so here are some haphazard thoughts:
1) You're writing a PHP/MySQL app. It doesn't matter if it's a game or the next big social networking site. There are holes common to all web apps (check out the OWASP Top 10). There are also holes common in PHP code, such as remote file inclusion. There are things you can do wrong with JavaScript. Learn about them, learn about how to prevent them and write your code accordingly. Security should be part of development, not something you tack on afterward. This means using good coding convention (i.e using parametrized queries instead of concatenation, always encoding output, etc) and ensuring that any design decision you make does not compromise the security of your application. Make sure security is multi-layered as well. For example, even if you think your app is 100% free of SQL injection (wrong assumption!), you still need to make sure you've properly hashed user passwords in the database in case they're exposed. (Side note: please don't use MD5 for this; look into bcrypt, or at least many rounds of SHA-256 or such.)
2) Harden your environment. No amount of hardening will stop all attacks, but it may help mitigate their impact, and if you're lucky, it may thwart some script kiddies or automated scripts. Running PHP? Harden the crap out of your php.ini (magic_quotes_gpc, turn off fopen() for URLs, etc). Think about installing the Suhosin patch. Just don't get complacent; there are ways around all these protections and they are not a substitute for secure code! You may also consider a web-app firewall (WAF), in the vein of mod_security, but don't fully rely on these either. If you're publishing code for others to use, don't ever count on your users to implement these same protections in their environment.
3) Web app scanners can help, especially if you're a novice with security, but once again, they will not catch everything (probably not even a lot of things.) There's skipfish, NetSparker and free versions of some of the more commercial scanners.
4) I know your question was whether to publish your code. I say "Yes", but this is a personal opinion -- I just happen to think it will give security dudes more of a chance to audit your code, and attackers will find your vulnerabilities anyway, through poking at your app and fuzzing even if nothing is published.
I hope that helps a little!
Who are these "common people" you're talking about? At least you give them credit for knowing what the Internet is. But since they've, ostensibly, been on the Internet before, why do you think a Photoshop on a government site would somehow make them revolt against their government?
Did you forget about the Google Summer of Code and multiple other projects where they basically fund the development of OSS tools?
Previous astronaut tweets had been posted by a third party on the ground via email.
So, then, they did have SOME access before?
What DECAF giveth, DECAF taketh away.
I'm a resident too, and I love this city to death, but I also know too well about Toddler Stroger and his antics.
When you say "local sheriff", it makes it sound like he's the sheriff of some small town. In fact, Tom Dart is the sheriff of Cook County, which contains Chicago, is the second most populous county in the U.S, and his department is the second largest in the U.S.
People claiming Dart is drumming up publicity are pretty much correct. Keep in mind, we're talking Chicago here, so consider the history of the political machine here. Dart also refused to evict renters from houses when their landlords lost the mortgage. In a way, this is an honorable thing to do, but the way it played out, everyone read it as once again more publicity for Dart. The Craigslist case just further proves his motives.
Does anyone else worry about sending sensitive information over a service like Twitter, which has had security issues in the past? And, assuming this works over DMs, what if a user instead accidentally uses a reply or just a straight Twitter post? What sort of information have they just inadvertently exposed?
You have to wonder why this kind of thing can't just be easily implemented using Twitter's API, instead of having to pay them for it.
Aside from the usual gripes about the efficacy of pen-testing, this gives pen-testing a bad name. The firm I work for does this exact same ploy, and so do teams from the Big 4 and various security firms, but they are always planned ahead of time. You have to do this sort of thing in a controlled manner (or as controlled as possible.) Usually, these things are dropped in a parking lot, the the payload is innocous, because a customer (or member in the case of a CU) can pick it up. These guys exposed themselves to a lot of liability and can screw it up for honest hardworking sellout hackers such myself and others.
Hasn't FlightStats.com been doing something similar for years, just without the trendy technologies?
I wonder what kind of Internet connection they have there?
So, sex offenders aren't allowed to use LinkedIn, but they're allowed to use AIM, Yahoo and chat rooms? Interesting approach; this is what happens when the government tries to regulate something they know nothing about, and take the easy approach of using overarching, way-too-generalized statements.
Please tell me you don't seriously think they did this to get away with not paying for parking.
I am guessing this was meant as a troll/joke, but, you may to actually put a real command in there.
Did you bother even reading the article? The code is in httpd.c, which obviously handled both types of connections. I almost hate SSL sometimes because people equate it with security -- but not encryption or integrity, but that somehow it's a magical fix-all for whatever the security flaw is. I see this kind of thinking in IT people in charge of the enterprise and it scares me. Security is not about having a setting enabled, and it certainly requires much more analysis than a simple dismissive suggestion.
TrackIt! seems to be very popular with my clients, but it is a commercial tool and may be overkill for your needs. Still, it may be worth a look.
But there have been many browser exploits recently, and they've been in virtually every component of the browser. This flaw has nothing to do with JavaScript itself, just the implementation. Flaws have been found in XML and HTML rendering engines, third-party components, URL handlers and many other pieces of the browser. If we're going to disable every feature that's potentially vulnerable, we might as well stay off the Web.
In my humble and largely anecdotal experience, Postini works well. We send out e-mail that can often be flagged as SPAM when we perform penetration testing, and Postini seems to be the toughest to get around. We see in-house devices such as IronMain, and outsourced services such as MXLogic and FrontBridge/hosted Exchange, but Postini seems to do the best at stopping illegitimate messages. The company I work for uses this it as well, and logging into my Postini inbox I see a lot of spam but no false positives. I think it's a pretty good solution if you don't want to handle SPAM in-house.
They run XP embedded, which allow you to customize which components are used much more so than regular XP. That is not to say I don't see your point -- we've broken into plenty of Diebold XP ATMs during authorized penetration tests using regular Windows exploits. After that, it's game over with the software this product mentions. Then again, regular OS's have been running on ATMs for a long time, and many still run OS/2.
Though I haven't had a chance to evaluate it just yet, I think this is a step in the right direction. Flash security is often overlooked, while Flash itself is often overused by designers who think that pretty effects make the web page. It gets especially bad when Flash is used for activities that require some sort of security, such as a login form. 99% of the time, instead of POST'ing that information to a server side script, it's handled inside the SWF file. Since these can be easily decompiled (grab a copy of Flare or any other decompiler), the password is easily revealed. I recently found a network product which went through the trouble of XOR'ing a password and storing in a text file. Two problems: the text file was in the web root, and the XOR key was inside the SWF. Tools like this can only raise awareness of these types of issues.
I don't know about it nearly crashing the Internet. How many people actually noticed a difference that day, for that matter?
A lot of admins, especially after the alert went out over the NANOG list, set their routers to reject long ASPATHs (or I assume, from what I saw on those list, I am not a BGP admin myself.) Many routers simply rejected these ASPATHs as well; correct me if I'm wrong, but weren't old versions of IOS the only ones affected? It was a serious issue, but I'm not sure if it came anywhere near a disaster scenario.
Closed source applications have to be audited with fuzz testing and other techniques, and this means that bugs can hide from the "white hats" (or the company) for a long time. Look at the bug fixed by MS08-067; it was discovered in the wild as part of a trojan and is now at the center of one of the biggest worm breakouts in history. Open source software can be fully audited by third-parties, including through techniques such as static analysis. I am not anti-closed source per se, but calling it somehow more secure because it "can't be verified" is the opposite of the truth. Tell your customers to talk to a security professional, not a salesman.