What Happened in the Security Attack to PHP.net? - Lately in PHP podcast episode 41 - PHP Classes blog

Contents

Listen or download the podcast, RSS feed and subscribe in iTunes

Watch the podcast video, subscribe to the podcast YouTube channel

Read the podcast transcript

Introduction (0:20)

PHP 5.5.5 and PHP 5.4.21 releases (2:08)

More Secure HTTP Requests with TLS Verification (8:19)

Detecting Man-in-the-Middle Attacks with Certificate Pinning (11:34)

Class Autoloading Security Exploits (13:15)

New PHP Defects Found by Coverity Scan (19:38)

Pass True by Default to session_regenerate_id() (23:13)

Is Wordpress Secure or Not? (31:24)

Sentinel Tool for Auditing the security of PHP code (38:16)

Protecting Browser Side User Data in JavaScript using Cryptography with secStore.js (42:31)

What Happened in the Security Attack to php.net? (46:06)

JavaScript Innovation Award Winners of August 2013 (1:06:50)

PHP Innovation Award Winners of August 2013 (1:11.56)

AppSec USA Event (1:22:12)

Conclusion (1:26:40)

Introduction (0:20)

[Music]

Manuel Lemos: Hello, welcome to the Lately in PHP podcast/hangout. This is Episode 41 and this will be a special episode because I have here with me a couple of guests, very experienced in the security world.

First, I would like to introduce Chris Cornutt because he's a well-known figure from the PHP world, from the PHPDeveloper.org fame. Hello, Chris. How are you doing?

Chris Cornutt: I'm good. I'm good. How are you?

Manuel Lemos: I'm fine. It's a bit hot over here. Here in Brazil it's heat season and the rain season at the same time. And I'm kind of all wet in my arms but I have a fan on my side. I hope you are not listening to the fan.

Anyway, other than Chris, we also have a very special guest... Jim Manico from the OWASP. Hello, Jim, how are you doing?

Jim Manico: Good. How are you doing today, good sir?

Manuel Lemos: Well, I think we'll have a great show. And there's a reason why I invited these guests to this show. As I mentioned, they are experts in the security world. And this all ties into the event of the attack to the PHP.net site, about which we will comment a bit ahead in this show.

PHP 5.5.5 and PHP 5.4.21 releases (2:08)

Manuel Lemos: And as always, we have quite good interesting topics to cover. I have focused especially this edition about security topics. The only non-security specific topic, or probably maybe still related, is about the latest releases of the PHP 5.5 and 5.4.

Let me just share the screen here. And on the side, I think I need to increase the font.

So, basically, there was the recent PHP 5.5.5. It's the usual batch of bugs that were fixed. I don't know if there was any of these that is security related. Also, there is the release of 5.4.21 which basically seems to be a similar set of bugs that were fixed.

Chris, did you follow this release? Are you using the latest PHP releases or you usually wait until it becomes more stable, so you don't get caught by the latest bugs?

Chris Cornutt: Well, usually it's more of what's required by the company or by the project. I think the highest I've used so far is 5.4. But yeah, I'd like to use 5.5. I just can't roll it out whenever I feel like it, unfortunately.

Manuel Lemos: It's up to your company to decide. You don't a have a say on that?

Chris Cornutt: Well, it's not the easiest thing to shift major versions.

Manuel Lemos: Right, right.

Chris Cornutt: Lot of planning involved.

Manuel Lemos: Right.

Jim Manico: As we say in the Java world, "Write once, debug everywhere."

[Laughter]

Manuel Lemos: Right, yes.

Chris Cornutt: Yeah, no kidding.

Manuel Lemos: Yes. I also have somewhat similar phrase. It's that "New versions, new bugs."

[Laughter]

Manuel Lemos: So, you're probably are using a newer version without some of the old bugs. But probably, you will get caught new bugs and you still don't know what's worse.

Anyway, Jim, are you following the PHP releases in terms of security aspects?

Jim Manico: Well, look at that, I saw a validate URL. Can we take a look at that one? That looks interesting to me.

Manuel Lemos: Yeah, let me share.

Jim Manico: Let's share that one up there.

Manuel Lemos: Let me share the screen again. Validate URL - yeah, I think it's a flag. Yeah, it's still security related.

Jim Manico: Yeah. Think of like different social networks where users post up a URL as part of their message, I think this is one of the functions you may want to use to check if it's a valid URL or not. Anytime I see 'validate anything', that's something that we might use as a security control.

So, let's go take a look at that. "It fully rejects qualified..." I can't read this.

Manuel Lemos: Rejects fully qualified domains.

Jim Manico: Oh, here we go. I'm on my cellphone being driven around downtown Houston. It seems to work right now. So, I'm on the move on this podcast. I'm on my little iPhone here.

Manuel Lemos: Yeah, it's a bit difficult.

Jim Manico: Oh there we go. Perfect. "Fully rejects qualified domain names even though parse_url() parses them." Oh!

Chris Cornutt: Yeah, I was trying to go through the pull request on it and figure out what the difference was. Looks like they're just using two different RFC definitions for it. So, it looks like they may have merged them. I don't why they would have used two different ones.

Manuel Lemos: Well, I was not even aware of what is the syntax of domain with the dot in the end.

Jim Manico: I thought PHP was renowned for having like ten functions that do the same thing in a slightly different way.

[Laughter]

Manuel Lemos: Well, sort of.

Chris Cornutt: Well, so, parse_url() is getting the pieces of it. It's filter when it's referring to specifically about data filtering. So it's kind of the same functionality, I guess.

Manuel Lemos: Right.

Chris Cornutt: Sounds a little bit more like that.

Jim Manico: So, maybe one is validate, just the VALIDATE_URL function use the parse function maybe as part of its operation.

Chris Cornutt: No, I think there were two different pieces.

Manuel Lemos: OK.

Chris Cornutt: The FILTER_VALIDATE is part of the filter_var function.

Jim Manico: Got you.

Chris Cornutt: It's just one of the filters that can imply to it.

Jim Manico: Now, whenever I have VALIDATE_URL function, I want it to be actually pretty strict. I want to be able to ask questions of that function. Things like is it an HTTP URL? Am I allowing HTTPS URLs? Am I allowing a HTTP or JavaScript URLs? I also want to ask if I would allow relative half-type URLs. So, I like those options.

These are functions that I need to do validation, if they're in the language with enough configuration natively, that's ideal. Usually, we have to use some kind of third party library to get some of the extra validation features.

Manuel Lemos: Yeah. Well, personally, I'm still stuck with the regular expressions. For some reason, I feel more comfortable with the... Since they work in the older version. So, I think in my URLs that I validate, I do not even accept one domain that ends with dot. I don't even know what is the meaning of dot. But OK, since it's not a regular type or URL, I would not accept it.

Jim Manico: Got you.

Manuel Lemos: Well, anyway...

Chris Cornutt: Yes, I think that is the whole debate.

Manuel Lemos: Yeah.

Chris Cornutt: Go ahead.

Manuel Lemos: Anyway, moving on with the podcast, there is not much to say about this latest releases. Probably there are some related topics with the security but it's not easy to figure all them up.

More Secure HTTP Requests with TLS Verification (8:19)

Manuel Lemos: Anyway, moving on with the hangout. There is a proposal here to make TLS peer verification on by the... This is the proposal.

[Noise]

Manuel Lemos: This is the proposal. Jim, can you read it?

Jim Manico: Yeah, very well.

Manuel Lemos: I don't think it's very secure to try to read screens and drive at the same time, but OK.

Jim Manico: I am not driving. I am a passenger. Hal, say hello.

Hal: Hello.

[Laughter]

Jim Manico: I am a passenger. So, I am on the move.

Manuel Lemos: Oh, you fooled me.

[Laughter]

Manuel Lemos: Well, anyway, regarding this, this is a proposal that's still under discussion on the... I think most HTTP clients in PHP would not enable the TLS verification of the peers. I mean, verifying the peers is really what it is and probably that could cause some security issue.

Jim Manico: So, this is when using PHP as a client language and it's about client-side cipher support?

Manuel Lemos: Yes. Because...

Jim Manico: Oh, like calling out to a Web service or something of that nature.

Chris Cornutt: Correct. Yeah.

Manuel Lemos: Right. If you do not verify the peer, I think you are vulnerable to Man-in-the-Middle attacks I think. Because you are not verifying if the certificates of the server are valid and so on. I think that's what it means.

Chris Cornutt: Yeah, it is.

Jim Manico: Not easy to do correct at all. Any kind of a blight crypto is brutally complex to get right. So ideally, you can find some kind of wrapper class that does this for you really well. And especially if it's an application where you're spending money, I wouldn't mind even buying a paid-for component that was well enough supported. This is really hard stuff to get right, unfortunately.

Manuel Lemos: Yes. Well, PHP supports it but I think at least when you use the curl extension, there is an option to do this.

Chris Cornutt: Yeah, there is. The RFC for this is actually proposing it to be implemented down at the stream level, which would go even lower than like the socket open and all that kind of stuff. That's the base level of any of those requests.

So, it would be better to implement it there than necessarily trying to... I mean, you could use a wrapper like Jim was saying but this would have it a little bit lower level into the language.

Jim Manico: I got you. I got you.

Manuel Lemos: Yeah. Well, I think at least for more security sensitive sites, this should be a must in terms of securing the application because you could be retrieving, for instance, accessing an API that's probably a fake API with a Man-in-the-Middle attack. So this is a...

Chris Cornutt: Yeah, there was actually...

Detecting Man-in-the-Middle Attacks with Certificate Pinning (11:34)

Jim Manico: One thing you can do to help detect fraudulent certificate-based Man-in-the-Middle attacks, when someone has a private certificate to a certificate authority and can make fraudulent but CA-validated certificates, you can use a technique called certificate pinning.

This is just taking the public certificate of your SSL server and hardcoding in the client in some way. And then, when you make your SSL handshake, if someone hands you a fake version of your website but a CA-valid one that your client would normally validate, it would detect this and reject. This is called certificate pinning.

It's a little off topic. I don't see it in the patch or the problem here. But it's something to consider to make your client's site connection stronger and it's not that difficult to implement.

Manuel Lemos: Well, I did not even follow all you said because I'm not familiar with it.

[Laughter]

Chris Cornutt: Yeah, I think the way they've been talking about implementing it, it would be easy enough to do that kind of thing. Because essentially you're just defining the certificate as a part of the actual request. So, I don't think it would be overly difficult to do that kind of thing.

Jim Manico: As in OWASP Resource, we have a guy called the OWASP Certificate Pinning Cheat Sheet written by Jeffrey Walton. Something that's worth reading if you really need super locked down client-side TLS type of services.

Manuel Lemos: Right. I think I'll look it up and put it in the Show Notes because that's always interesting for security sensitive applications.

Jim Manico: Yup.

Class Autoloading Security Exploits (13:15)

Manuel Lemos: OK. This was one proposal that's still under discussion.

And now, moving to another topic, this one it's more at the PHP source code level... let me share the screen here... which is... Well, I don't know if this is really exploitable. This is a message in the PHP Internals from Jordi Boggiano from the Composer fame.

Well, this is not related to Composer but related with namespaces, because namespaces separators eventually turn into directory separators.

And if you have... I don't know, I probably read from some variable, some namespaces with .., you probably can make the PHP code load some class that is actually some malicious code can perform and exploit.

Chris Cornutt: Right. So the basics of this, the idea I think that he was trying to get across is, a lot of the autoloaders will just take the path that's being requested and take the namespace and flip and make it into directory separators.

If somebody uses like a $_GET var and puts in something that's not filtered and the script uses that as part of the half or as part of the namespace, there is a possibility of a ../ or whatever making it in there because it's not validated.

Jim Manico: Is this used like when I type a URL into a browser and sent to a PHP application, is this function parsing that URL in any way?

Chris Cornutt: Yeah.

Manuel Lemos: No, no. This is not really a URL, this is the... There is in PHP, in the latest version, there is the concept of namespaces. So, you can organize your software in packages and a package can contain many classes and they'll be included, it's on namespace.

And if you define a namespace that has a name probably defined dynamically eventually from a non-secure source of a value like, for instance, a GET or POST request variable, it could sort and inject this malicious paths that could make the PHP code load some malicious class instead of the real class that it was supposed to be loaded.

But this is a part of an unusual case because who would actually define the namespace of classes to be loaded dynamically from some unsecured source of value? Well, I don't know.

Chris Cornutt: But it can be done, that's the problem.

Manuel Lemos: Right.

Chris Cornutt: There's nothing preventing it.

Jim Manico: So, this is like when untrusted data is concatenated to this namespace in some way...

Chris Cornutt: Exactly.

Jim Manico: ...and then sent to the autoloader. That's the problem.

Manuel Lemos: Yeah.

Jim Manico: So we want the low-level PHP APIs that do this to be secure by default in some way. They've edit some defense in this low-level API?

Chris Cornutt: Right. But the tricky part is the same require statements, they're usually used for the autoloader's 'do allow'.

[Laughter]

Chris Cornutt: They do allow the .../ and all that , because they're requiring file path.

Jim Manico: Got you.

Chris Cornutt: So, it would be a little, I'm not sure how you would even implement it at the base level. You'd almost have to end it, do it in the userland code and have it actually check for that kind of stuff before you do the required...

Manuel Lemos: Right. Well, this is sort of unusual but as Chris said, it's possible. Well, the proposal here is basically to have some control on the PHP side to prevent accepting ..'s or any names with dots or only dots. Because dots are the ones that change the current path to some other directory.

Chris Cornutt: That's exactly why it was talking about whitelisting of class names and all that kind of stuff since there are only certain characters you can use in PHP class names.

Manuel Lemos: Right.

Chris Cornutt: I don't know if any RFC came out of it or not. I didn't see one.

Manuel Lemos: Well, maybe this is not a big concern, but it's still yet another possibility of exploit that should be closed to prevent some careless programmer uses it and causes some security problem.

Chris Cornutt: I think just advocating good use of that kind of stuff in the userland code would go a long way. I don't know if it necessarily needs to be something implemented at the language level but trying to protect developers from themselves only go so far.

Manuel Lemos: Yeah. Many of the advances in security terms in PHP were to protect the developers do the wrong thing.

Chris Cornutt: Yeah.

Manuel Lemos: So, I think this would be another one.

OK, I think Jim dropped his connection.

Chris Cornutt: Yeah. I'm sure he'll be back.

Manuel Lemos: Yeah. Well, it was quite amazing that he actually made it.

Oh, there he is.

Chris Cornutt: Hey.

Manuel Lemos: And you're back.

Chris Cornutt: Speaking of which.

Jim Manico: Been driving down the highway didn't get and stop me, but the elevator did.

Manuel Lemos: Oh, that explains it.

Well, you did not miss much.

New PHP Defects Found by Coverity Scan (19:38)

Manuel Lemos: Just now, we are going move on to the next topic, which is this time related with something that I was not even aware existed, which is... I think it's a tool called Coverity that is used to scan code. In this case, it's C code.

And, I don't know, this seems like a commercial tool that the PHP core developers have access to audit the PHP project code.

And this is message from Rasmus saying that it's reporting some defects. Well, this is for those that are more acquainted with the C programming that goes on in the PHP implementation site.

Chris Cornutt: It looks like they've been using it for quite a while actually because I'm seeing messages that go back to like 2006.

Manuel Lemos: Right. Rasmus was mentioning there are new defects. It seems there were also old defects.

Chris Cornutt: Yeah.

Manuel Lemos: Well, it's interesting. It's good to know that this is a sort of concern with the preventive security because this tool is reporting some defects. Probably, those are potentially sources of security exploits, I think.

Chris Cornutt: It looks like dead code, unused code, all that stuff that needs to come out.

Manuel Lemos: Right. Jim, do you know this tool, Coverity?

Jim Manico: Well, before you just say it needs to go out, the code needs to be reviewed. More than anything, it would be... I'm sorry, the vulnerability report needs to be reviewed in triage by a security expert.

Because some tools, most static analysis and dynamic analysis tools have some kind of false positives. So, I don't want to take this at face value. I want to go in and look at them, investigate them, test out certain areas.

Code does very strange things. There's different ways to hop into code that has now static analysis tool may say is dead, that's really not for some other bizarre reason.

So, we need to analyze. Don't rip the code out. We want to do a proper analysis before we make those decisions. So maybe they're there for good reasons. Who knows?

Manuel Lemos: Yeah. Well, it's good to know but for the most of us, the PHP developers that do not work with the core, this is out of our jurisdiction, I think. But I think it's good to know it exists, that they're having some serious concerns with the security of the PHP implementation.

Jim Manico: Some quick things for C++ developers, another OWASP Cheat Sheet. This is a non-profit free guide from Jeff Walton again. It's called the Toolchain Hardening for C++ programmers to use certain compiler flags and build environment that gives you maximum security in the build environment.

So, we'd love to do deeper analysis of what's really happening here and how they're building PHP from C . But, yeah, I definitely want to use this kind of tools in the development of that kind of code, for certain.

Manuel Lemos:  Right. Well, I also mentioned about a somewhat similar tool but it's more at PHP source code level, but we'll get there.

Pass True by Default to session_regenerate_id() (23:13)

Manuel Lemos: So, now moving on to the next topic, always related with security. It's about one related with the PHP function session_regenerate_id.

Let me share the screen here if you can read it.

Basically, this is a function that makes PHP switch to the new session ID. I suppose that when this function is used, they also switch the cookie, the identifier of the cookie, that identifies the PHP session.

Jim Manico: So when it changes the ID, does it make the older ID invalid as well? Or this is just another sub-ID for the same question?

Chris Cornutt: Basically.

Manuel Lemos: Well, that's the topic here because this function takes a parameter that if it is false, it will not delete the old session data. And the poster here, Yasuo Ohgaki... I'm sure I'm not pronouncing his name right, please excuse me... suggests to turn it on by default.

Jim Manico: Now, wait a second. This one is saying whether or not it deletes the old data. Now, that's important, but I also want to know if it invalidates the old ID. There's a vulnerability to accept session fixation so when a user authenticates, I want to invalidate the old session ID and regenerate a new session ID.

I might want to maintain the same session state or some of the session state or just add to the old session state with authentication data. But the most important security thing for me is whether the old session ID is still a valid ID, whether or not the data cache of the session is wipe out or not. Makes sense?

Manuel Lemos: Right. I did not double check on the documentation about this. I think if the old data is not deleted, the previous ID is still there as the file name. Because by default, PHP uses files to store session data.

And in this case, I think the old ID probably remain as valid for a while, but I could be saying rubbish. It could be totally not this, I don't know. Do you know any more details about this, Chris?

Chris Cornutt: I was looking at some of these comments. It looks like when it's regenerated... Well, it's hard to tell. I know it does create the new ID and it copies over the session information to that new session, but it doesn't say if the garbage collection for the actual session handling happens right then or if it relies on the garbage collection for whatever is storing, whether it be the file system or memcache or whatever it is.

Manuel Lemos: Right. Because there is also the garbage collection process that, after a while, it removes the old...

Chris Cornutt: Oh, no, there it is right there. Delete the old session parameter, it says, whether delete the associated session file or not. So, yeah, it would invalidate the session and it would invalidate the file removing file or memcache record, whatever, however the handling's set up. So, yeah.

Jim Manico: So, that means the old ID would no longer be valid when you wipe out the session file.

Chris Cornutt: Yup, exactly.

Jim Manico: Cause that views the session ID like entry in a hash table or what-not that looks up a session. So, yeah, when you want to do session... Why would you ever want to do this without wiping out the old session? I can't think of a reason.

Manuel Lemos: Right.

Jim Manico: So you want to... Is this default to wiping out the data when you don't set the parameter?

Chris Cornutt: Yeah. That's what this proposal is about. Right now, it set the false by default because of an old duplicated behavior.

Jim Manico: Is this default to when you don't set parameter it...

Chris Cornutt: I think we lost him. Oh, no.

Jim Manico: No. We like default as secure defaults.

Chris Cornutt: Well, I'm not,

Jim Manico: We want this change, even though it will make everyone's app all buggy and crazy.

Chris Cornutt: The joys of hotel WiFi.

[Laughter]

Jim Manico: You want to air on the side of deep secure defaults.

Chris Cornutt: Yeah, yeah. Absolutely. And I think he definitely has a point.

Jim Manico: 3G... I'm on 4G right now.

Manuel Lemos: OK. Maybe WiFi is more secured.

Jim Manico: It's not working out?

Chris Cornutt: It's kind of cutting in and out a little bit. Actually, not as good when you were in the car.

Manuel Lemos: Maybe the structure of the hotel is preventing the signal to get through.

Jim Manico: Strange. I'm going to jump on the hotel wireless. I'll be back.

Chris Cornutt: OK.

Manuel Lemos: OK, let's see if it works. That's quite an insecure step, talking about security.

Well, anyway, as we are talking. I don't know if this... The problem of this for me but I'm guessing many things here.

Jim Manico: Even though I'm using hotel wireless, I'm using HTTPS.

Chris Cornutt: Good.

Manuel Lemos: OK, makes sense. Can you listen? Are you still there?

Chris Cornutt: Yeah, he is.

Jim Manico: Yeah, I'm here. I can hear you guys loud and clear.

Chris Cornutt: OK, good.

Manuel Lemos: It was funny because it seems that you,

Jim Manico:  Charge, keep going.

Manuel Lemos: It seems the video is a bit delayed. I mean your video is a bit delayed when compared to the audio.

Chris Cornutt: That's all right.

Manuel Lemos: That should be fine.

Anyway, well, regarding the topic of having security by default, this has always been as far as I can remember, a great struggle between the PHP core developers and the security experts.

I think it was Stefan Esser, if I remember correctly, that sort of was always fighting the PHP core developers because they were opposing to change things that could break the compatibility and could cause more trouble than they actually solve. It will be more secure but it would also break the PHP applications.

Chris Cornutt: Potentially. I know there's a lot more people that are more involved in working with the core that are a little bit more security -minded. I think people are realizing that there's certain parts of the core language that need this kind of work on it.

 A lot of the RFCs that have come up lately had been more about preventing bad default behaviors. And it's good to see the trend continues.

Manuel Lemos: Right. Trying to fix the programmer without rebooting the programmer, reprogramming the programmer, because there are programmers that are sort of hopeless.

Manuel Lemos: OK. Anyway, this was an interesting topic. I'm not sure if it's still under discussion, if I'm not mistaken.

Probably, they will get to a conclusion because there are some people that oppose to changing the default. Maybe they will change the default to the next measure version like 5.6 or something. So, by then, nobody...

Chris Cornutt: It's like now the RFC is still under discussion. I don't think they've did any voting on it yet. They would be included in the 5.6, if it's out there. So, let's see.

You were saying?

Manuel Lemos: It's usually what happens.

Chris Cornutt: Yeah.

Manuel Lemos: At least nobody cannot complain that they are not doing anything to make PHP more secure by default.

Is Wordpress Secure or Not? (31:24)

Manuel Lemos: Well, anyway, moving on to the next topic, actually, it was something that I added later to the list of topics, which is the debate that goes on and on the WebmasterWorld forums, specifically at the WordPress forum.

There is a guy here that is asking if WordPress is secure or not, and if you feel it's not secure, you should prove it.

Well, there is no 100% secure application now. But the question is whether the WordPress security concerns are moving on fast enough or maybe they lag up a bit much because WordPress is widely deployed PHP application. If there is an exploit, it will certainly affect many many sites.

So, personally... Yeah, go ahead.

Chris Cornutt: I was just going to say one of the things I know, they've done a lot of work in the recent years about improving the actual security of the core. It's not the most ideal code in some places but they've done a lot of work on it.

And unfortunately, it's gotten kind of bad rap in the past because a lot of the problems had been with the extensions of WordPress, the modules that you can drop in there.

I mean, I'm sure Jim has got horror stories. I'm sure that he can tell bad WordPress extensions.

[Laughter]

Jim Manico: It's more than that. When you say WordPress is secure or WordPress is not secure, WordPress is not a model that they think. Not only are there a million different configuration settings on WordPress but there's also, like you were saying, there's tons of add-on modules written by a variety of different developers with all different levels of assurance.

[Laughter]

Jim Manico: So, you know, I'll be saying when you say is WordPress secure or not, that's not the only thing that's a fair question. Is the default installed? Does WordPress have a certain version secure on this OS with this level of security patches and configuration? So, it's a complex question.

Manuel Lemos: Right. Well, maybe the question should be, is there any effort to audit the security of the plugins, at least those that are listed in the WordPress repository?

But I know that's kind of an impossible mission because there are many, many thousands but at least the most popular ones should probably deserve more attention.

And I don't know if you guys noticed, but I've seen somewhere that there are services for installing WordPress plugins that they actually do the auditing. I don't know if it's the auditing of the security or the features. Because there are some plugins that they are not unsecure but they do some things without the permission of the developer.

I've read, for instance, about plugins that plant links to the sites of whoever developed the plugins, so the plugin developer earns certain links that probably are worth some benefit in terms of Google ranks.

But those are not really security concerns, but it's only safer to get plugins from somebody that did serious effort to at least audit at least part of the code.

Chris Cornutt: Yeah. It's really hard to tell that stuff. And you know, honestly, there's some plugins out there that are really very popular and really widely used, but the actual code behind them and all that is just not ideal.

And you can't tell unless the person has specifically said on the plugin site that they've actually paid attention to security that now you can't trust them. It's just like any other third party library. You have to go in, you have to go evaluate what it's doing and be sure it's not, you know, hiding the malicious things on there, hiding random stuff in your pages.

Jim Manico: I'll tell you this. I'm not going to use WordPress for like enterprise software to run my business.

[Laughter]

Jim Manico: I'm going to put it out there for marketing website. I'm going to keep it isolated, back it up regularly, back it up off the server and assume it's going to get owned, and be ready to deal with that.

Manuel Lemos: Yeah, for the third time.

Chris Cornutt: So, Jim, would you use Drupal then?

Jim Manico: Pardon me?

Chris Cornutt: I said would you use Drupal then?

Jim Manico: Look, I don't want to like,  No, I'm not.

[Laughter]

Chris Cornutt: I'm just giving you a hard time. I'm just giving you a hard time.

Jim Manico: The White House used Drupal.

Chris Cornutt: Yeah, I know.

Jim Manico: The White House used Drupal and they pulled that thing down really fast. Look, it is what it is. I can do some really nifty thing with a different PHP CMS really fast.

But I'm not going to put ultra-sensitive data into it. I'm going to back it up and pull it back off of the server. I'm going to isolate it from other parts of my enterprise and assume it's going to get owned because there's so many developers who've written code that drives the heart of Drupal and other systems.

And, I don't know, the security is getting better? Sure, it is. But I'm  going to use it for lower risk things. That would be my choice.

Chris Cornutt: Yeah, absolutely.

Manuel Lemos: Well, there's nothing perfect, so it's probably a discussion that would not lead us anywhere, but OK. Well, so the answer to whether WordPress is secure or not is that don't ask that question.

Well, anyway, moving on,

Jim Manico: One more thing. So, my buddy Robert Hansen, "Rsnake", who I worked with, he ran WordPress running ha.ckers.org for a long time and minimally got owned.

And he did all kinds of crazy things to make it locked in. So, I think you should go and hunt him down, just send like a roving reporter to his house... I'll tell you where he lives... and just interview him on the spot how to lock down Wordpress and I bet he can give you really good answer.

Chris Cornutt: I'm sure he'd appreciate you saying that, too.

[Laughter]

Chris Cornutt: Send people to his house, yeah.

Jim Manico: But the key thing is when he did describe it to me once, it's not a small effort. It took gargantuan steps to really lock down WordPress.

Chris Cornutt: Yep, unfortunately.

Jim Manico: So, let's go hunt down Rsnake. If I was in Austin right now, I'll just immediately drive over to his house and knock on his door and ask him. But, oh well, I'm in Houston.

Sentinel Tool for Auditing the security of PHP code (38:16)

Manuel Lemos: OK. Also related to this topic, the next topic is about tools that eventually could help to detect security issues with PHP code.

I found this announcement here from a company, WhiteHatSecurity. I'm sure there probably other companies with their own products that probably do a similar thing. But I thought,...

Jim Manico: Now, wait a second, hold your horses. I am one of the vice-presidents of WhiteHat Security. I'm very biased and I don't want to do a sales pitch on your podcast.

Manuel Lemos: That explains your picture, it was on one of their pages.

Jim Manico: No, no, I don't think it is. But if you see my picture there, let me know, I want to see it. Yeah, I do work for WhiteHat which means there's no way I can objectively talk about this, right?

Manuel Lemos: OK.

Chris Cornutt: Well, you could fill us in a little bit more on this support possibly.

Jim Manico: All right.

Manuel Lemos: Yeah. What does this do for sure? I suppose you know it in detail.

Jim Manico: Do you really want me talk about the product that I work for at White Hat? Look, I'm part of the sales team, part of the marketing team.

And I didn't come here... I don't want to go on your podcast to sell product, but if you want me to give you a quick little blip of what it does, I'll do it. But I'm taking off my objective security professional hat and I'm putting up my safe prostitute hat. If that's what you want me to do, I'll do it.

[Laughter]

Manuel Lemos: No, no, just tell us what it does in a few phrases.

Jim Manico: I'll do a few phrases. This is the brainchild of Eric Sheridan and Jerry Hoff who started Infrared which got acquired by White Hat. This is the central source product, PHP source code review.

Jim Manico: It's not really a tool. It's a service, like you deploy a virtual machine of our engine in your environment. It checks out the code every day, scan the code on premise with 9,000 plus rules and counting, sends the results back to WhiteHat or a SaaS-based service. We review the results, and then we pass back verified results. So there's no false positives.

Remember earlier with the Coverity issue, it found bugs in the core PHP. They might be real, not just in Coverity, but you still need to triage those vulnerabilities. So part of the WhiteHat service, we do the triage. We do it like for a year subscription, so it's constantly grinding, scanning, verifying every day. And done.

Chris Cornutt: Is it just static scan or is it dynamic scan, too?

Jim Manico: You're going to talk to jerry.hoff at whitehat.com.

Chris Cornutt: Come on. Come back to us, Jim.

Jim Manico: ...in a wild fashion. So, I'm going to get everyone, just hammer him with questions.

Chris Cornutt: And of course... I think you're going to have to put that one in the Show Notes.

Manuel Lemos: Yeah, it's the censorship.

Jim Manico: So that's my quick pitch. Welcome to chop it up. But I'm really proud of what Eric and Jerry have done at White Hat. So, I give them a lot of props for building it. This is pretty cool. This is good stuff.

Chris Cornutt: Yeah, yeah. And the more things like this that can be offered for PHP and PHP applications, the better. I mean, I know there's tons of tools out there, but the more offerings, the better.

Manuel Lemos: Yeah.

Chris Cornutt: Thanks.

Manuel Lemos: Yeah. Two disclaimers, first, I was not even... I was  not aware that you were working for that company. I added this topic late to the topics of the hangout. So, you probably did not see it.

And the other disclaimer is that the part that you're trying to mention the email address of the person that I should contact, the audio came out garbled, so it was not my fault. It was not my censorship. For some reason, it stopped working.

Jim Manico: Yeah. I didn't come on your podcast to sell product. You're welcome to cut that section out.

Manuel Lemos: No, no. It's always useful.

Jim Manico: Let's go, next topic. Next topic.

Protecting Browser Side User Data in JavaScript using Cryptography with secStore.js (42:31)

Manuel Lemos: OK, the next topic is... Actually, I wanted to move on to the topic on which we'll talk about the PHP.net security attack. But then, I remembered there is an article that is interesting, also related to security which is in the JS Classes site.

It stopped the screen sharing. Let me get back to that. OK, there, it's back.

OK, this is an article written by Jason Gerfen. He developed JavaScript component that uses cryptography to store values in the local storage or cookies, which are basically containers that can be used to pass information to the server, also to the next page of JavaScript applications.

So he has written this article, the title is 'Protecting Browser Side User Data in JavaScript using Cryptography with secStore.js', which his component. And basically, it tells us how the component works and we'll use cryptography to store the sensitive data on the browser side.

For those not familiar, local storage is just sort of an area on the browser side that applications can use to store additional information. It's not like cookies that go back and forth between the every request into the server.

And I think this is interesting but I was not even sure exactly where the key to encrypt and decrypt the data would be stored because I suppose it's not also on the browser side.

Because if it's also in the browser side, it probably will not be secure as well because an attacker of the machine where the browser is installed would have access to all the information. You need to decrypt, eventually, sensitive data.

I don't know if you guys ever dealt with applications that use local storage to store sensitive data. Any experience with this?

Chris Cornutt: No, not directly.

Manuel Lemos: Yeah. Well, anyway, this is interesting. We even also comment on the JavaScript hangout, more about this. But it's basically what I said, it's interesting but it would always be good to analyze where the key to encrypt and decrypt data would be stored.

And, well, this is just a brief mention about this article. Whoever is interested about this, also the browser side, not just the PHP server side, can take a look and eventually learn what Jason has done with this component.

What Happened in the Security Attack to php.net? (46:06)

Manuel Lemos: So now, we are finally moving on to the topic that this probably what is more intriguing related to the security in the PHP world, which is the one related with the attack that happened. I was even trying to look here the exact date but it was like last month 24th of October.

Chris Cornutt: Yeah. It was either the 23rd or 24th. I don't remember what date it was actually reported, but they first gave the status of data on the 24th.

Manuel Lemos: Yeah, right. And here, the still on the homepage of the PHP.net site, they are basically saying that they are still analyzing what happened.

They found out a few services that were compromised and they were replaced to be analyzed. At least, until now, I don't think there was any result coming from whoever analyzed this. Even if they reached to a conclusion, I'm not sure if they will announce it publicly soon.

I don't know, Chris, have you followed this? Do you have any more news regarding this attack?

Chris Cornutt: No, nothing I've really seen. Nothing other than what they posted. There was a little bit of discussion on the mailing list about it, but like I've mentioned earlier, there really hasn't been any official post-mortem on all this stuff that I've seen. I know everything is back in business from what it was.

Manuel Lemos: Right. Yeah, they just replaced the servers and moved on. But it would be interesting to know what happened.

What we know so far is that there was a JavaScript file that I think was loaded from static.php.net that got replaced by the attack. And this is curious because sometime ago, it also happened to I think it was PHP Classes that had one JavaScript file replaced.

I couldn't reach a conclusion how that happened but I tried to at least verify all the versions of the software that I was using were up-to-date. But in the end, I did not get to a conclusion.

Jim, does this scenario ring any bells? Do you have any clue what would have happened there?

Jim Manico: A website got attacked, I'm so surprised.

[Laughter]

Manuel Lemos: No, I mean, in this particular case of PHP.net?

Jim Manico: JavaScript malware? The question is how did the JavaScript malware get on the site and is attacked? Was it like the server is rooted to a traditional attack of some missing patch? Or was it cross-site scripting because maybe some admin was popped and some cross-site scripting entered the site, to the admin console?

I'm curious how the JavaScript got there. I can talk ad nauseam what JavaScript malware can do. What? We can redirect the user. We can conduct port scans against their client. We can steal their session. We can deface the site or steal data off the page or set up keystroke loggers on JavaScript. Once you get JavaScript on the webpage, that browser is yours. You own the browser as the attacker. So, that's pretty nasty. No wonder why they took it down for a while and fix the problem.

So, that's my question. Can you scroll up, how did the JavaScript malware get there in the first place?

Manuel Lemos: Right. That's the downside that we don't have yet. They are still analyzing it and since they are still analyzing, the only thing you can do is to guess. So, I was wondering if this is a pattern of an attack that you know, that is familiar to you, replacing a JavaScript on a static server that is running Nginx. Does it ring any bells or maybe too generic?

Jim Manico: Yeah. There's a couple ways JavaScript could get entered on the site. Suppose someone has administration console that lets them update to frontpage of a website. And you might just give that administrator a big text area and they can type in whatever HTML they want. But that's a highly elevated privilege user who's not going to enter an attack when he submits new content.

So we give him admin access, a big open text area and let him submit whatever markup he wants. And that might be safe for a while because, again, only trusted users have access to this feature.

Now, suppose that I set up a fake request that auto-updates the content if I was the administrator and I put it on my evil website. Now, that's no good because I'm not logged in. But if I can trick the admin while he's logged in to visit my evil webpage, that's called cross-site request forgery that I could make a Submit to the administrator's update field, just probably using a standard CMS and I add JavaScript malware that way. They see it and take down the site.

Like you said, I'm guessing. And I haven't done a lot of research on this. From what they said on the site there, they don't know how the JavaScript malware got there either. Or maybe it's like that was a chat feature or an advertisement was on the page that had JavaScript malware on it.

Or someone attacked the server at the network level and you've got a root kit or whatever your network attackers do and from that point, they just updated the JavaScript file. There's so many different ways that JavaScript could have gotten on the site. Who knows?

Manuel Lemos: Yeah. So, no help from the...

Jim Manico: Was there an advertisement widget on this page in any way?

Chris Cornutt: No. No. The one that ended up being on the page, the malware that was there was, I think, they said it was appended to another JavaScript file. It was already being downloaded like a userprefs.js or something. I forgot what it was exactly.

Jim Manico: So, someone modified an existing JavaScript file...

Chris Cornutt: I believe so.

Jim Manico: ...added a malware through an existing JavaScript file in the server.

Chris Cornutt: Yeah. They've actually on this, by the website, they've actually got a good post. They did it back on the 24th. They were analyzed. They went through it and figured out exactly what the malware was and what it was doing. And they even offered some mitigation stuff it.

Jim Manico: If it was added to a JS file, then that doesn't seem like cross-site scripting.

Chris Cornutt: No.

Jim Manico: It doesn't seem like cross-site request forgery. This seems more like a lower level attack, not even against layer 7. Like a lower level attack against the server and someone just updated this file.

Manuel Lemos: Yeah. What do you mean exactly by a lower level attack. Maybe some exploit of the kernel of the system installed in the server?

Jim Manico: Not that low. Just maybe not up... Well, let me try this again. Maybe it's not necessarily a Web attack layer, maybe it's an attack against like some Man-in-the-Middle, some file update protocol like FTP or SFTP or something.

Manuel Lemos: Oh, yeah.

Jim Manico: Maybe the server was out of patch and the server got rooted and whoever took ownership of the server decides serve up JavaScript malware. Who knows?

But it's not likely a Web layer attack, like a classic OWASP Top 10 type of Web attack. It looks like a different kind of attack.

Chris Cornutt: Yeah, it was injected on there and desiccated, of course.

Manuel Lemos: Right. Well, what I remembered what happened those many months ago, and if I remember correctly, it was on a file that was served, in my case, by lighttpd. And it's the same thing. It's a server that is used to serve only static content like JavaScript, CSS and pictures.

And the lighttpd changes the root of the process that is serving the files to some restrict area of where the files really are. So, I don't know if whatever was the attack could have gone outside that the root area that lighttpd changes.

But OK, that's my case and it's not necessarily same thing that happened in PHP.net

Jim Manico: Did you see how this was detected? I think that's pretty interesting.

Chris Cornutt: How was it detected?

Manuel Lemos: Yeah. Google told the world.

Chris Cornutt: Yeah.

[Laughter]

Manuel Lemos: It's the most embarrassing way. Google told Chrome to tell the world that this site is infected.

Chris Cornutt: So, what I think happened is it wasn't propagated fully and Google happened to come across the right instance of that JavaScript file and caught it, and then locked the entire PHP.net domain. The Wiki was down, the Git server was down, the website was down, everything was blocked by Google.

Manuel Lemos: Yeah. Because I think probably that file is included from the other domains. It's not used by static .PHP.net. It's used by other domains that,

Chris Cornutt: Right. I assumed that Google hit that and said, Oh, PHP.net is serving malware, so anything under PHP.net, we're going to block it.

Manuel Lemos: Yes, and,

Chris Cornutt: They can get that removed and taken off the blacklist.

Manuel Lemos: Right. This is terrible.

Well, other than that, Jim, do you have any advice for us muggles programmers that are not so security-experienced on what to do to prevent and also to deal with the situation after it happens.

Jim Manico: Well, the key thing to do is have continually rolling backups of your site and those backups pulled away from the Web server in a separate backup.

Just prepare to get hacked. You're going to get hacked. It's going to happen, especially when you're using some of these different open-source tools without a lot of assurance work put in to lock it down. Just prepare to get hacked. Have a rolling backup  every hour that migrates that backup file off your server in some way.

And I want to cite my sources. I'm reading Dan Goodin's ArsTechnica article, Hackers compromise official PHP website. And one the authors, Grooten in here, he says that "This is not likely someone overriding the file.

This is likely someone who's attacked the Web server. And then, maybe some like a Web server malware that's residing in memory in the Web server, probably because of missing patch or even the patch window of the security problem being released and the patch being available.

Suppose that window is a couple of minutes when PHP knew about it and updated it right away, that's enough of a window for attacker to take advantage of the right kind of vulnerability to get malware in the Web server and then that malware from the Web server attack updated the JavaScript file and edit the malware.

That's what I'm reading in ArsTechnica article. The professional who said this was the case looks like he was from Kaspersky Labs, Martin Grooten who quoted in Dan Goodin's ArsTechnica article. Those are my proper references from that wonderful idea.

[Laughter]

Jim Manico: So, yeah. It's not like... What I was saying is, even if it's Layer 7. It's application, but it's not like the Web application layer being hacked. It's not something a programmer could have done to fix the problem, it's the Web server.

So, the problem was most likely patching issue of the Web server and the Web server getting owned. That's seems reasonable with the evidence we're looking at. But who knows?

Manuel Lemos: Yeah. Well, actually, I was even looking here. I remember that somebody... probably sometime ago, I think one or two years ago... developed a PHP class that would actually scan all the files that you have on the server and it would sort of get an hash of each file.

And it would regularly verify if the files were changed, so that it would determined if eventually you are hacked and somebody changes the files like in this attack.

I don't know if this can be done efficiently when you have too many files to verify. But, well, it's an idea to deal with a situation where you already found out that you were attacked.

So, with a component like this, you could be made aware that you were hacked even before Google tells you about it, which was the case.

Jim Manico: So that's not,  No, I'm sorry.

Manuel Lemos: Yes. No, just,

Jim Manico: That's not intrusion prevention. It's intrusion detection, at least when these files,  It sounds like tripwire. It sounds like a tripwire kind of technology.

Chris Cornutt: Yeah.

Jim Manico: It's something we do at the OS level where you get hashes of different files that you do not expect to change. So yeah, it seems reasonable if setup correctly. Sure, why not.

Manuel Lemos: Right. It certainly follows your advice to prepare to be attacked. It's going to happen anyway.

I'll have to look again because it was even nominated to the PHP Innovation Award that goes on PHP Classes site every month. The idea was unusual and so it was nominated, but I'm failing to remember the exact name. I was not able to find it here.

But well, we still have to figure what exactly happened, but at least we should be warned and follow your advice to prepare for the eventuality of being attacked and, as you suggest, have backups and place to be ready to at least minimize the damage, at least minimize the eventual loss of having your site down.

And this also brings to me one topic that I want to ask you, Jim. It's about defensive security. Very often, when I go to take a look at resources, sites, articles that talks about security, most of the times that I take a look it's always talking about attacks. It's dealing with the so-called... Dealing with attack is not exactly what you can do to prevent or at least minimize the damage of those attacks.

Do you have any sites that you could recommend other than OWASP that could provide good advice on how to deal with these situations in a more defensive way? Not just be concerned with the specific types of attacks, but also what you can do to minimize the eventual damages that can happen once you are hacked?

Jim Manico: So, there's the idea of being proactive about building secure applications. There are tons of OWASP resources that talk about this. I work on a project called the OWASP Cheat Sheet series. One of them is a PHP Cheat Sheet.

There's a lot of breakdown. We tried to have like a one-pager on every security topic of a software developer, like an XSS Cheat Sheet, a Cross-Site Request Forgery Cheat Sheet. There's one on all these different topics in application security.

Jerry Hoff built the series called the Appsec Tutorial Series. That's a little series with a couple videos, high-level videos, on application security.

There's also another non-profit called SAFECode that Howard Schmidt started. Just go Google SAFECode. It's a bunch of very high-quality videos, like official SCORM-compliant training modules to let you go through secure coding education.

So, those are a couple free resources I've looked at that helped to develop right secure applications.

Manuel Lemos: Right. So, on those sites, we'd find that advices like when you mention of having the backups ready to deal... to restore eventual loss after an attack?

Jim Manico: Still, there's two  different like levels of advice. That's more infrastructure. I'm recommending like a rolling backup, like every hour and that backup file being pulled off your server sent to another server.

So if your Web server is hacked in some way, the backup has been pulled off the system, you can go to a backup previous to the hacking incident, fix the bugs hopefully and then go live again.

The other kind of defensive advice is less infrastructure. It's more how to write software in a secure fashion. Things like input validation, proper password storage, using like scrypt instead of hashing methods, which are weak.

You want to use like an adaptive password storage algorithm... again, like bcrypt or scrypt or PBKDF2 for your password storage. Advice like doing output encoding to stop cross-site scripting.

Other advice to use like the synchronizer token pattern. These things are built into PHP usually to stop cross-site request forgery, or doing a frame busting header to stop clickjacking.

So, we have all these different... Depending on what level of security and what level of assurance you need, it's still good to be aware of this secure software coding practices.

Probably, the most important one is how do you write database queries when using like PHP, PDO or other database access libraries. Some people are going to stop this with magic codes. It's not very magic. We have problems with that.

So you want to use a technique called Query Parameterization. That's how you should be writing PHP, a little cheat sheet, the Query Parameterization Cheat Sheet. This is a way to stop SQL injection when doing database queries in PHP.

So again, I like, again, the SAFECode organization, a lot of free videos on secure coding. As a board member of OWASP, how can I not point to different OWASP projects that talk about secure coding.

There's even a password - a PHP, I'm sorry... There's even a PHP Security Cheat Sheet that's worth taking to look out. It's in Beta, but there's still some good information though. They might want to take a look at.

There's also Keith Turpin's Secure Coding Checklist Project that can help you build secure applications.

So, there's definitely a lot of resources and it's becoming where a developer needs to... Developers are getting pressured to build secure applications more and more because we're seeing incidence of Web hacking on the rise and the damage being done is also on the rise. So, this is becoming a lot more important in recent days.

Any questions about secure coding to your audience, I'm always happy to answer questions on jim at owasp.org.  And if I don't know the answer, I'll find someone who does. I'm always happy to answer to answer secure coding questions.

Manuel Lemos: Right. Those are great tips. And then I appreciate it if you can pass me the links, at least the most important ones because you mentioned quite a lot of resources to get listed. So, it would be interesting if you can pass and so, I'll put them in the show notes.

Jim Manico: I'm happy to give you all.

Manuel Lemos: OK.

JavaScript Innovation Award Winners of August 2013 (1:06:50)

Manuel Lemos: Well, we are approaching the end of this hangout on which, basically, there are couple of regular sections on this. We'll just mention a few classes that were nominated to the Innovation Award. This is no longer specific to security. It's just a regular section. And since this Hangout is already a bit long, we're just moving on quickly to that.

And I'll start. Let me open here the winners. Okay, it's here. Let me increase the font here.

Well, we'll start by the JavaScript ones. We'll talk about the JS Classes nominees for the Innovation Award. Specifically, this site is for JavaScript and we may start mentioning those that were released in August and then they were nominated in September. And then, in October, the results came out. There were like three nominees.

We already talked about this before between me and Chris. Chris, which one you would like to comment about this JavasScript?

Chris Cornutt: Of the three, the Extended Number one probably sounds more interesting.

Manuel Lemos: Yeah.

Chris Cornutt: The number handling in JavaScript is less than ideal sometimes. So, I haven't really gotten a chance to look at it but from the description, it sounds interesting.

Jim Manico: Luckily, in the Java world, we have no problem with number handling. Just kidding.

Manuel Lemos: Now, this is other Java, this JavaScript.

OK, I'll try to open here the... It's easier than ever figuring the... Oh, it's the one...

Jim Manico: Manuel, what I was trying to say is there's problems with number handling in every language. Robert Seacord, secure coding guru for the C and C++ language, he wants to have a security conference and a huge week-long conference on integers, just on integers.

[Laughter]

Jim Manico: He's half-psychotic but the point he's trying to make... He is psychotic but the point he was trying to make is we could have a conference talking about just integers for a full week, because this is a complex topic and most every language has problems with number handling in some way.

I think there are at least in C, there are safe number higher level advance classes that might be slower but have more precision when dealing with certain numerics. So that's something to consider.

Manuel Lemos: Yeah.

Well, in this case it's a simpler solution. It's actually very basic. It's by the one that Chris was mentioning, it was a component developed by Martin Barker from the UK.

It just added... just created an object that extends the basic number objects in JavaScript and adds a few more functions that deal with some functionality that very often needed but it's not built-in... like checking if the number is odd or even and checking if the number is floating point or is an integer. But this is a very, in general, simple component.

And the ones that I'd like to comment are the other two. There are only three nominees in this month. There is one that was developed by Mark Rolich from Armenia. He developed a component that lets you measure areas of page elements on screen.

And these are somewhat unusual component but he developed this component probably to deal with a situation that he faced when developing his own Web applications.

And other than that, there is also a component by, in this case, by Vallo Reima from Estonia, which is basically one of those components that let you pick dates. In this case, let you pick a couple of dates to define a range, beginning and the start. There are many components that let you pick dates but this one is for ranges and it was quite interesting.

And this is just to mention very quickly that here in the PHP hangout, we also try to promote some components of the JavaScript site because it's still a younger site and does not have the quantity and the variety of the components like the PHP Classes.

PHP Innovation Award Winners of August 2013 (1:11.56)

Manuel Lemos: So now, we'll just move on to the winners of the Innovation Award of the PHP Classes site which, in August, have much more nominees. In this case, there were like 11 nominees.

Chris, which one you would like to comment?

Chris Cornutt: Let's see. I think I was going to look at that SMS Authentication, mainly because of the whole two factor possibilities behind that.

The service that it uses is a commercial service. But I looked at it earlier and they do have a little trial thing that you can try it out if you want to see if it will work for your app.

Manuel Lemos: Yeah.

Jim Manico: For really secure applications, I would not use SMS. It does have some problems. Check out, there's another good article about how Twitter ruled out multi-factor.

They're using more of secure protocol. It's more of push notification. We have a private key on your device. Asymmetric handshake is going on between you and Twitter servers, and they give you a push notification of the Twitter app and you just hit OK on.

I'm a real big fan. They really thought out what a secure protocol is when they built that, sending a six-digit or eight-digit code over SMS. Don't get me wrong. It's a huge step in the right direction, especially for consumer grade services.

But for really deep security, I think you want to look even deeper like a dedicated token or the secure protocol that Twitter's multi-factor simulating through their client.

And a real quick note, the whole purpose of multi-factor is to stop brute-force attacks without having to use account lockout. Normally, you'd write... If you just did password-based authentication to stop brute-force, you want to count lockout where after so many tip, you lock the account.

But if I know all your account names or usernames, then I can use that against you. So multi-factor will stop this brute-force attacks and you can turn off account lock out in the face of multifactor, I think.

Manuel Lemos: Right.

Well, using SMS messages seems to be a more popular solution. I was not aware. So you're saying using that Twitter uses push notifications to communicate with the user and validate device because it's a physical thing to validate its account. So, I wasn't aware of that. It's interesting.

Anyway, this component by Andy Dixon from UK implements something that is generic in terms of two-factor authentication. Well, there are many... there could be other alternative but this seems to be quite common. So, it's an interesting solution.

Jim Manico: I still give it two thumbs up. It's a step in the right direction, not enough websites are using two-factor. It's on the rise and I think SMS is a great first step. It's definitely better than password-based authentication by itself. So, I'll give it a secure coding, two thumbs up, two thumbs up.

Manuel Lemos: Yeah. Well, that reminds me, sometime ago my son lost his Google account and he was desperate because he wanted to play Minecraft and whoever got his account also took over the Minecraft account.

Chris Cornutt: Oh, no.

Jim Manico: Did they build any cool things with his Minecraft account?

Manuel Lemos: I don't know. I would have to ask him.

[Laughter]

Jim Manico: All right.

Manuel Lemos: Well, what saved his account is that, originally, I informed some alternative address of mine... it was not of my son ... and I went to look at my archives to find that message, because Google asked when was the account originally created and I have all the information in that message. And I was able to quickly recover it without human intervention. I mean I did not talk with anybody with Google.

So, it was great to know that they have this means to recover stolen accounts. And my son was happy again because he was able to play a Minecraft with his original account again. But I still have to go through a separate step to recover the Minecraft account which was not as easy as Google.

Anyway, that was just a side comment. So, moving on the Innovation Award,

Jim Manico: That would be an awesome,  Ask your son what kind of hacky things this would be. Like supposed we hacked someone's Minecraft account and then just put like bunny rabbits all over someone's castle or something or  take someone big Minecraft building and painted all shark cruise or something like that and then log out. That beat you. To some people that would be a terrible hack.

Manuel Lemos: Well, I don't know. My son was just seven by then. I don't know how terrible it could be to... I suspect it was a so-called friend of his. He probably asked his password for some reason and then hacked other counts that he could.

Jim Manico: Let me tell little Lemos, what's your son's... Well, whatever your son's name, don't give away your password to anybody. I think that's what happens.

Manuel Lemos: That's something, well, once in a life, we have to tell explicitly. So, it was my fault I did not tell him when he was seven.

Jim Manico: How old is he now?

Manuel Lemos: He's 12.

Jim Manico: All right. So, this is great. We have a security learning moment for your son. Son, don't give away your password. I know your dad told you to share and with other things in your life, it's good to share. But your password,

Manuel Lemos: I already told him.

Jim Manico: Don't even tell your dad. Nobody get your password but you. Nobody. Ever.

Manuel Lemos: My mother-in-law used to tell my wife so that "You should never trust, not even your mother," and she was the mother of my wife. So, a mother telling her daughter she should not trust anybody, not even her mother, is quite a strong advice.

Jim Manico: That reminds me of my Math teacher. I was taking differential equations, I was like, "Professor, you wouldn't fail me, would you?" And he looked at me really evil. He's like, "Jim, I would fail my mother."

[Laughter]

Jim Manico: So, OK.

Manuel Lemos: OK, now we have gone pretty off topic. So back to the topic of the Innovation Award nominees, which other class you would like to mention, Chris?

Chris Cornutt: Let's see.

Manuel Lemos: Is it the Kindle one?

Chris Cornutt: Which one? Yeah, the Kindle one.

Manuel Lemos: Yeah. This is interesting, just not related with the security I think in any form. This has to generate...

Chris Cornutt: Right. Just sounded interesting.

Manuel Lemos: ...Kindle e-books. This one is from Sergio Vilar from Brazil and it's basically to help compose Kindle e-books using HTML files. There's probably some security related with the Kindle DRM but I think it use this just a wrap-around the tools Amazon provides. It's nothing that the class itself controls because it does not do it by manipulating the files directly.

OK. Now on my part, I'd like to comment on... MySQL Cluster Import is one of the classes that I'd like to comment. This one is from Nadir Latif from Pakistan.

It's actually quite simple in what it does. It just generates some shell script to migrate the MySQL databases so they can work in a cluster. And what it does is quite simple but very effective. It just execute some alter statements and what was interesting for me is that I was not aware... because I've never worked with clusters... that it's just that, changing the type of the tables. So, although innovative, it's quite simple, this class. 

And the other class that I want to mention... let me get back to the list here... it's this one, writing applications to process input from the command line shell.

Basically, this class makes it easy to deal with some command keys like the cursor keys and backspace and the tabs to implement shell-based applications more quickly, especially those that deal with history of commands, go back to the old command and added it and execute that command again. So, I thought it was very innovative because it simplifies the job of those that need to develop shell applications.

AppSec USA Event (1:22:12)

Manuel Lemos: Well, basically for this podcast, that's all. But Jim wants to talk about the AppSec event, right?

Jim Manico: Sure. The OWASP Foundation is having a conference in New York City, AppSec USA. This is going to be in New York City at the Marriott Marquis. And we'd love to have you there.

And OWASP is, of course, a non-profit foundation. We're a 501C3 not for profit in the US or non-profit out of Europe as well. This is in November 18 to 21st. That's this month. And if you like more information, take a look at appsecusa.org.

And this is an application security conference. There are plenty of sections where software developers discuss different topics around secure coding.

So, I hope to see you there. Any questions, just drop me a line on jim at owasp.org. You can look online. This is appsecusa.org as well.

Manuel Lemos: Right. And will there be any PHP-specific sessions or just Web development in general?

Jim Manico: Let me take a look here. So, let's go AppSec USA PHP. I'm not sure but I'm going to check right now. You can just feel the excitement in the air here.

[Laughter]

Jim Manico: I'm not sure. I'm not sure. Let me see what we got here. Schedule, yes everything to schedule.

Manuel Lemos: Appsec.org, right?

Jim Manico: Appsecusa.org and we're a Web application security think-tank non-profit.

Let's see what we have here. Here we go. Analysis.

Manuel Lemos: Yeah, I was trying to search.

Jim Manico: Yeah, at 1:00, November 18th, there's the OWASP PHP Security and Role Based Access Control Introduction being given by a Abbas Naderi, who's coincidentally the OWASP chapter leader in Iran, I believe. And Abbas is also doing the PHP Cheat Sheet for the OWASP Cheat Sheet series.

And again, on Monday, November 28th at AppSec USA, there's going to be section. The aim of the session is to introduce attendees to both projects and to get them working on the projects and related activities.

We want to demonstrate, introduce the OWASP PHP Security Project and get more PHP security thinkers to work together to help enhanced the PHP Security Project at the OWASP Foundation.

So, there's one PHP event. This is more like a workshop going on November 18th and Abbas is one of the more senior PHP security experts within the OWASP organization.

What else do we have going on here?

Manuel Lemos: Yeah. These are like a long sessions. So, I think those are workshops, right?

Jim Manico: Well, there's the PHP announcement again. Go look at the November 18th part of the schedule, scroll down to 1:00.

Manuel Lemos: Yeah, that's what I thought.

Jim Manico: Across that and then click in on that link. There we go. Let me read this out. So, this is a multi-hour section happening from 1:00 to 5:00 on November 18th at appsecusa.org. So the aim of the session is to introduce attendees to the OWASP PHP Security Project and the Role Based Access Control in PHP project that Abbas is working on.

So, and yeah, so go take a look at AppSec USA under the schedule.

Manuel Lemos: Yeah. I'm on the page.

Jim Manico: And get some more information. And I hope to see you there. We'd love to have some PHP, steep PHP Security thinkers there so we can take this information about  building secure PHP applications and build open-source content and open-source articles so we can get the word out to help people build secure Web apps as much as possible.

Abbas has been doing a lot of work on this area. So, thumbs up to him. Hope to see you there.

Manuel Lemos: OK. That's good to know.

Well, this Hangout is going to be transcribed and then it will be published. Let's see if it can be announced in time so more people could go to the event.

Conclusion (1:26:40)

Manuel Lemos: Well, basically, we have reached the end of this hangout. I would like to thank you both for coming. I think it was very interesting to discuss this security-related topics.

In my experience, not just speaking for myself, but security is usually a boring topic for developers probably because we are not so well aware of all the details. But, OK, that's my opinion. So, with more information, people eventually become more interested and for their own sake, at least minimize the damages eventually at their sites.

So, again, I would like to thank you both for coming and on my behalf, that is all for now. Bye.

Chris Cornutt:  Thank you.

[Music]