Slashdot Mirror

It's only a security threat if you can't trust the site that the programs are originating from. Sure, this search engine *may* be able to dump a tracking code into their output and therefore break the TOR privacy[1], but you have to ask how likely to happen is this? And my answer: very unlikely.

Please. If you do not understand the fucking problem. Do the world a favor and shut the fuck up.

http://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-gregory_fleischer-attacking_tor.pdf
http://ha.ckers.org/blog/20060704/cross-site-scripting-vulnerability-in-google/
http://www.xssed.com/news/41/A_new_critical_Google_XSS_vulnerability_promptly_corrected/
http://shiflett.org/blog/2005/dec/googles-xss-vulnerability
http://blogoscoped.com/archive/2007-09-28-n28.html
http://www.h-online.com/security/news/item/Google-fixes-cross-site-scripting-vulnerability-in-YouTube-comments-1032988.html
http://ibnlive.in.com/news/orkut-attacked-by-bom-sabado-worm/131714-11.html
http://www.geek-news.net/2010/09/twitter-hit-with-major-xss-hack.html
http://lynnepope.net/twitter-xss-attacks
http://nemesis.te-home.net/News/20090407_Metasploit_Decloaking_Engine_and_TOR.html
http://securityandthe.net/2008/12/23/finding-a-hidden-ip-address-just-got-easier/

A couple of good questions I have seen, and my best attempt to answer them:

1. Don't you mean rel? No, I mean rev. It indicates a reverse link.

2. Why not make your URLs short in the first place? I happen to like my URLs and have made them as short as I want them. They're only too long in some very specific use cases, like Twitter. I could just complain about Twitter, or I could support an idea that makes URL shortening suck less. I chose the latter.

Thanks for reading, and please do feel free to criticize whatever you think is wrong with this idea. I'd like a way to indicate a preferred short URL for my own stuff, and this seems like a pretty good way to do it that makes sense semantically and is easy to implement. For an ongoing discussion about adding an HTTP header to do the same thing (so that only a HEAD request is required), read here:

http://shiflett.org/blog/2009/apr/a-rev-canonical-http-header

First off, why do long URLs even matter? Is this link too long? Ahhh, you don't even care, because it's a normal link! But let's say the length is a problem. On the linked page, the author suggests that he could have his site also provide an alternate shorter URL for the same page, and have the HTML href tag encode both the long and short versions. Here's what I don't grasp: why not just use the short URL to begin with, and never even post the long one?!? No new HTML features are needed.

Yeah but PHPulse scales. Seriously though, if you want to go down that road, you would see that PHPulse has the highest benchmarks for speed and scalability in a PHP framework. So while RAILS may have had that for years, PHPulse has scaled for years. Come talk to me in 5 years when Rails can do that and work in the enterprise.

In fact, most Ruby sites use PHP still in order to scale. And yet, somehow, Ruby fanatics still deny this to this day... sad really.

However, an even better thing to do (then just create a read-only user), is to escape shit before you query the DB... PHP and MySQL have this nifty function mysql_real_escape_string [php.net] which will do that for you. It is better then using the general escape functions in PHP, for reasons that I read just recently. Basically, it takes into account the character encoding for the DB... http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

Please repeat after me: String escaping is the wrong answer to SQL injection.

Now please move rapidly toward using prepared statements.

Also, setting up a least privilege is still a very good idea. That should be considered as required for any internet facing database.
Alex

This is a very good point. Except that phpMyAdmin makes it really easy to set up a new database with a single user who has all rights, and the same name as the DB.

So what I tend to do (and I do admit that I am a lazy SOB), is just create a new DB and user for every app.

However, your idea is much better, and it would be nice if phpMyAdmin had such a feature... (Not that I'm about to code it in, on account of my being busy with other things, and never having even looked at the phpMyAdmin code beyond what is needed to install it.)

However, an even better thing to do (then just create a read-only user), is to escape shit before you query the DB... PHP and MySQL have this nifty function mysql_real_escape_string which will do that for you. It is better then using the general escape functions in PHP, for reasons that I read just recently. Basically, it takes into account the character encoding for the DB... http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

So it may be partially C# or just that Microsoft web devs are inherently 'dumber'.

If you can no longer see them it's because they have show_php turned off in their php.ini. You can still spot what they are running on Netcraft and ask them why they are running PHP and they will tell you; they have responded in the past to such inquiries with what I am telling you.

If they no longer show it's because they have expose_php turned off but several of these sites still show. They have yet to resolve their scalability issues and this is a well known issue with RUBY and why no main website uses it in production; it's only for small blogs or news sites but nothing major.

Even 43things in their switch had to use 2 as much hardware to scale RUBY and they still had to fall back on PHP to get it to scale. The move was a nightmare (though the president keeps saying it was 'smooth').

Hell, even the Ruby, and Ruby on Rails site http://shiflett.org/blog/2006/feb/php-easter-eggs> need PHP in order to scale

If you use PHP4 you can use CakePHP or CodeIgniter If you use PHP5 you can use Symfony, CakePHP, CodeIgniter or the Zend Framework. CodeIgniter has good documentation and its 100% complete unlike CakePHP. http://codeigniter.com/ Of course PHP has many more frameworks than the ones I mentioned, there are probably well over 15, but those are the ones with the biggest amount of users. From what I've read the Zend Framework is more like a big library and lets you pick and choose what you want with no set structure. I've seen tutorials where others can use the Zend Framework with CakePHP, Symfony and CodeIgniter. The pros to sticking with PHP or a PHP framework is that you probably already know the language. Need security tips for PHP? Visit Chris Shiftlett's blog (he does a good job covering several issues, plus there are books on Apache Security and PHP Security, get them and read them). http://shiflett.org/ I dont see PHP dying anytime soon, there are way too many open source apps written in it, plus tons of new stuff is coming out, like SimplePie, and other good stuff. PHP Developer's web site has some good news on it. http://www.phpdeveloper.org/ Django and Rails have a downside to you having to learn a language and a framework and most often at the same time which makes things confusing for awhile. Django isn't 1.0 yet so while its stable, its still undergoing changes and nothing is exactly set in stone until the 1.0 milestone. Unfortunately there arent any Python books for just Web Development, so that makes it more of a challenge. Rails has a definate lead over Django, since there are well over 100 books on Rails and only like 2 planned for Django. Of course Rails was got more hype earlier on and came out before Django, plus the screencasts helped promote it, a lot. Pick whichever language or framework you want, there are pros and cons to them all.

Hell, even the Ruby, and Ruby on Rails site http://shiflett.org/blog/2006/feb/php-easter-eggs> need PHP in order to scale

Hell even the RUBY and RUBY ON RAILS people use PHP in order to get their sites to scale

Hell, even the Ruby, and Ruby on Rails site http://shiflett.org/blog/2006/feb/php-easter-eggs> need PHP in order to scale

There's also an iPhone security concern that's the fault of weak authentication in the AT&T/Cingular voicemail system:

http://shiflett.org/blog/2007/jul/iphone-security- concern

CSRF explained, albeit clumsily. The examples made the article. Solution: use POST requests for user actions, and add unique tokens to each form.

The safeguard you're describing protects against CSRF and has nothing to do with XSS.

Joel, I'm afraid it is you who aren't getting it.

I think Jeremiah Grossman says it best:

I'm not certain how wise it is to ask a network security guy's opinion about web application security matters. Maybe he cross-trains.

He's being funny, but he has a valid point. Here's an example from your comment:

A lot of Cross-Site Scripting attacks let you steal cookies. So they probably found those. But the question is: when you have a cookie, what can you do with it? Can you steal important data? Can you turn that cookie into a breach?

You shouldn't have to ask these questions, nor should you be suggesting that the worst thing XSS attacks can do is steal cookies. Show any competent web application security specialist a XSS vulnerability, and there is almost no limit to what he can do. I discuss some possibilities here:

Using CSRF for Browser Hijacking

Another example of "not getting it" is thinking IP addresses are unique and/or static among a large userbase:

Good web sites that use them also tie cookies to your IP address, which means that if you steal my cookie, you got nothing but crumbs.

Good web sites? You can't be serious.

If you are serious and want to really put your money where your mouth is, I'm sure you'll find no shortage of people to take it. Here's one:

$1000 to Steal Data From 30% of Sites

Using Ajax doesn't introduce new security vulnerabilities, but Ajax-enabled browsers do:

http://shiflett.org/archive/263

In case you're not kidding:

http://shiflett.org/archive/158

That's called CSRF, something entirely different:

http://shiflett.org/articles/security-corner-dec20 04

Nice idea, although there's plenty of danger even in read-only-land. For example, the example at http://shiflett.org/archive/184 is of an attacker who tricks a login scheme into letting him log in without a password, and the query there is merely a read.

I agree that prepared statements can be cumbersome, but they're clearly much more the Right Thing to be doing than constructing ad-hoc queries by hand, with random strings pasted between single quotes.

Your mention of "Query-by-Example forms" is apropos. Anybody know how to do those Right?

Microsoft ASP.NET version 2 also fights cross-site request forgeries with a MAC'ed token:
ViewState, ViewStateUserKey, andother ASP.NET security-related features

To save you futile Googling, be aware that Microsoft refers to cross-site request forgery as "one-click attacks".

Don't underestimate how important this attack is. To quote The PHP Consultancy, The most challenging characteristic of CSRF attacks is that the legitimate user is essentially making the request. Thus, regardless of how perfect the user identification and/or session management mechanism is, a CSRF attack can still be successful."

You should actually use mysql_real_escape_string instead of just mysql_escape_string or addslashes:

http://shiflett.org/archive/184

What are the credentials of Chris Shiflett? He's widely touted as a "PHP security expert", but Stefan Esser has a beef with him, and claims that this book contains serious flaws and misunderstandings.

I understand that people in the public eye like book authors are vulnerable to any crank that comes their way, but the problems that Stefan has highlighted do seem to point to a severe credibility problem, and Stefan, while prone to flaming, certainly knows what he is talking about.

In the interests of fairness, you should also read Chris Shiflett's response.

In the first case, this seems like an exploit of limited value. Great I can make you send the wrong data to a site, but what exactly would be the construction of this wrong data such that it would cause mischief. I can make you log into your bank as me... great... so you can log take all my money? I mean there may be some strange setup that this can be used to exploit but I should think it's a rarity.

You seem to miss the fact that some sites do not regenerate the session cookie upon login and reuse the session ID generated in a non authenticated area. This can lead to session fixation attacks, and, consequentely, to impersonation attacks. A malicious user could log in as a the user he "fixed" the session to.

Here's how it is done:

1. user A visits a malicious site property of user B
2. malicious user's B software generates a valid session cookie for site X (valid can be just properly formated, a valid hash or a cookie obtained from the site by accessing it without any authentication it depends on the application, really). This can be either static or dynamic
3. user A is provided a modified session cookie from site X (expiration date is set very far in the future) and the software keeps track of which user's have been given which cookies.
4. user A, later in the fure, goes to site X
5. site X does not issue a new cookie, the user's browser already provided one
6. user A logs in to site X
7. site X associates the session with the user authentication (like, say, store the session ID in a table matching session to user like many PHP scripts do or storing this in a servlet context)
8. user A uses the site
9. malicious user B goes to site X with the session cookie he provided to user A and can bypass the site authentication.

So the malicious user can impersonate the user at the site without authentication.

Of course, the problem here is with the site (steps 5 and 7), it should regenerate session identifiers, at the very least, when a user logs in. That way the authentication is associated with the new session, not the old one. However, you would be amazed to see how many sites (even banks) reuse the session identifier generated in a non-authenticated throughout a user's session, and only regenerate it when it's marked as invalid (authentication session timeout expired).

The scenario differs in the case you are handling software in which session identifiers expire even if not associated with a user session (Notice this is not typically the case for many application servers, as they don't include timestamps in sessions, typically applications will be in charge of expiring the session for authenticated users). In this scenario the malicious user B just needs to obtain the cookie from the remote server when the user A accesses his own malicious server and then redirect the user to the login of the site. This makes the attack a modified version of the traditional phishing attack, in this attack you are not asking for user's credentials since you do not need them to access the site once the user is logged in (the session ID is sufficient to access the site).

For more info check out WebApp Security threat definition for session fixation Chris Shiflett: Security Corner: Session Fixation

Sorry to see that you've been rated as a troll (16:11 GMT, 25th Jan 2006) You make a very reasonable point. Those who think they smell bullshit could do worse than read about mysql_real_escape_string() versus Prepared Statements, The addslashes() Versus mysql_real_escape_string() Debate and PHP Insecurity: Failure of Leadership. That said, I like using PHP. That said, I dread to think about the security state of my code...

The last article listed above contains this quote:
"For some time, I've been worried about the direction of PHP. As many of you know, I helped write XMB Forum and now help write UltimaBB. XMB in particular is an old code base, and UltimaBB, a descendant from XMB. I've done a lot to protect that code base from attack, and luckily, we've been missed despite some doozy and silly security issues. After writing PHP forum software for three years now, I've come to the conclusion that it is basically impossible for normal programmers to write secure PHP code. It takes far too much effort."

There's also the Zend Framework, to be released soon:

http://shiflett.org/archive/171

You might find this explanation helpful: http://shiflett.org/archive/177

Rails is a MVC framework built on Ruby.
PHP is NOT a framework.

If you feel like comparing/extolling the virtues of RoR compared to PHP, then try to at least be logical enough to compare RoR to a MVC framework built on PHP. There are several (though none as popular as RoR at the moment). Some are trying to imitate Struts and others trying to mimic RoR.

In fact, Zend is quite aware of RoR's popularity is in the process of creating its own framework to compete: the Zend Framework.

Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.

There's also the PHP Security Consortium, the Zend Framework (which will hopefully include most things on my wishlist as well as solve other problems), and a new input filter extension.

As BP says, it's a start.

Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.

There's also the PHP Security Consortium, the Zend Framework (which will hopefully include most things on my wishlist as well as solve other problems), and a new input filter extension.

As BP says, it's a start.

Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.

There's also the PHP Security Consortium, the Zend Framework (which will hopefully include most things on my wishlist as well as solve other problems), and a new input filter extension.

As BP says, it's a start.

Didn't they use quoting?
Maybe next time they might want to look here:
http://shiflett.org/articles/foiling-cross-site-at tacks

Maybe, but at least it looks like he hired the right people to prevent such a thing.

increasintly, if you don't have cookies, holding a session is impossible (unique id's on the getline are going the way of the dodo) and, increasingly, sites want you to maintain sessions to do anything useful.

For session tracking, cookies are now the standard, but there are other security precautions that can only accomplished by including a unique ID in every form.

Go read up about "session riding" or "cross-site request forgery". For example:

http://shiflett.org/articles/foiling-cross-site-at tacks

See the code sample near the end of the page, under "Force the use of your own HTML forms".

PHP's ease of use and flexibility do make for a dangerous combination. There's no arguing that.

I'm not so sure that the answer lies in the interpreter, although I'm open to the idea. In the meantime, the PHP Security Consortium is an effort to help educate the community about secure programming practices (among other things).

I also try to do my part (in addition to my work with the PHPSC) by providing free articles, giving various talks (including the PHP Security Briefing), and writing Essential PHP Security. Education might not be the only answer, but I think it helps.

So, you're right that there is a bit of a problem, but some of us are trying to help.

It allows for a manual recount, but more importantly, it allows for automatic recounts by more than one entity:

http://shiflett.org/archive/62

This could be a standard part of the tallying process, so that discrepancies that can possibly affect the outcome can be further scrutinized, so that the margin of error cannot realistically change the outcome of an election.

I think what they came up with at Foo Camp sounds pretty good:

http://shiflett.org/archive/62

It sounds like the Times agrees with what several of us discussed at Foo Camp:

http://shiflett.org/archive/62

Scalability is such a tired and misused argument, as you've just demonstrated. It's easier to argue that PHP scales than it is to argue that J2EE scales, but then scalability is just part of the picture. Read here for more information and perspective:

http://shiflett.org/archive/46

Also, PHP is behind a lot of huge sites, Yahoo being but one. Amazon.com uses a lot of Mason and Perl. Perl in the form of mod_perl powers a lot of major stuff. Python is important at Google. Where are these J2EE success stories that can justify the rhetoric that gets thrown around?

I think the stereotype that "everything that begins with the letter J is slow" is justified, with the exception of jBASE, and I hear those poor guys are thinking of changing the name of their flagship product because of it.

You're making an incorrect assumption. "SQL passwords," which I assume means the database access credentials, do not have to be readable by the Web server.

Well, that's too broad. Apache typically has a parent process running as root. Child processes actually handle the requests, and it is these that other users of a multi-user system can control using a variety of technologies (this is not language dependent). These processes typically run as nobody.

You can provide your access credentials to the parent process in such a way that only requests for your virtual host are given this information. I describe this technique in more detail here:

http://shiflett.org/articles/security-corner-mar20 04

Apparently this topic was discussed at Foo Camp.

I can't find any other links on this yet, but one of the comments pointed here. They all seem to have the same basic idea. That's very telling...

I have a few articles on my Web site that might be informative: http://shiflett.org/articles

I'm also writing a monthly PHP security column in php|architect, and these articles will be available for free six months after publication.

Lastly, I am writing PHP Security for O'Reilly, which is due out in the fall.

You can find out about SSL without buying the book. That is one of the free chapters:

http://shiflett.org/books/http-developers-handbook /chapters/18

I appreciate the honest feedback, and I'd like to address a few concerns/criticisms/whatever that I have seen mentioned.

Convincing the reader of the importance of HTTP - The first few pages do focus a lot on explaining why HTTP is important to a Web developer. Just look at all of the comments that mention how knowing HTTP is useless, and you can hopefully see why I think this is important. I see questions on various mailing lists all the time that reflect a general lack of knowledge in this area; developers don't really understand cookies, when SSL is needed (or what it does), how to secure their sessions (or applications in general), how to keep up with data from one page to the next, and all sorts of things.

The book caters to beginners - I want the book to cater to both the beginner and the experienced developer. HTTP isn't rocket science, and it can provide a great foundation for Web developers to build from. For those who are already experienced, the book can provide a good reference to the protocol (if you're experienced, you should also know that RFC 2616 isn't a substitute for this) and can help people gain a deeper understanding of things they already know a little about. I don't think a book has to confuse the reader to be considered advanced, and I wasn't writing to impress anyone. My approach was to try and help as many people as I could.

Learn Dreamweaver, not HTTP - Well, people with this opinion might be a lost cause, but what happens when your next place of employment thinks FrontPage is the only way to write Web applications? In general, I think it is better to teach people fundamental things and let them apply those things in any way that they want.

I also have a companion Web site for the book at http://shiflett.org/books/http-developers-handbook .

Some people might find this interesting. Users of IE 5.5 and 6.0 who also use Microsoft Passport are vulnerable to impersonation, as is demonstrated in the following article:

http://shiflett.org/articles/passport_hacking_revi sited/

Recall the first example of Passport impersonation that was published in 2600 that demonstrated how to compromise the account of IE 4.0 - 5.0 users.

Combined, this means that users of all versions of IE > 3 who also use Passport are exposed to a severe risk of impersonation.