[Music]
Lea Alcantara: You are listening to CTRL+CLICK CAST. We inspect the web for you! Today we’re talking about ExpressionEngine security with Matt Weinberg. I’m your host, Lea Alcantara, and I’m joined by my fab co-host:
Emily Lewis: Emily Lewis.
Lea Alcantara: This episode is brought to you by Peers Conference.…
[Music]
Lea Alcantara: You are listening to CTRL+CLICK CAST. We inspect the web for you! Today we’re talking about ExpressionEngine security with Matt Weinberg. I’m your host, Lea Alcantara, and I’m joined by my fab co-host:
Emily Lewis: Emily Lewis.
Lea Alcantara: This episode is brought to you by Peers Conference. Peers is a tech conference for designers, developers and web business owners that goes beyond the same old slide deck to curate a diverse group of speakers in development and business tracks bound to keep you on your toes. Want to learn something new? Love ExpressionEngine? Curious about Craft? Learning all about Laravel? Come and be challenged in the coding workshops. Engage with other attendees and hear what’s really going on in your industry all while having fun with plenty of time to network and chat. Whether you’re a pixel pusher, an artisan or a maker, Peers is for you. In its second year, Peers runs through April 23rd to 25th in downtown Washington DC. Register today at peersconf.com.
Emily Lewis: CTRL+CLICK would also like to thank Pixel & Tonic for being our major sponsor of the year. [Music ends] Hi Lea, welcome back. How was your vacation?
Lea Alcantara: In one word? Awesome. [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: Yeah, I know. It was so much fun. My sister and brother-in-law live in Ecuador so I really had a great local perspective on the country, and we kind of traveled the span. So I did some stuff in the mountains, I did some stuff in the Amazon, and I did some stuff in the beach. [Laughs]
Emily Lewis: Awesome. Well, if you had…
Lea Alcantara: So a little bit of everything.
Emily Lewis: If you had to pick just like the best highlight of the whole thing, what would it be?
Lea Alcantara: Beach.
Emily Lewis: Beach. [Laughs]
Lea Alcantara: Lying around doing nothing, drinking a juice.
Emily Lewis: Did you take like a lot of books with you, or music, or did you just veg out and enjoy the scenery.
Lea Alcantara: I did take one book, and mostly it was just vegging and listening to music.
Emily Lewis: [Agrees]
Lea Alcantara: Yeah.
Emily Lewis: Nice, nice.
Lea Alcantara: Yeah, that was nice.
Emily Lewis: Yeah, I really missed you. [Laughs]
Lea Alcantara: Oh, I missed you too.
Emily Lewis: Well, because I kept thinking about what you were doing while I was doing some stuff. [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: And so it was very stark contrast, but I’m glad that you got such a nice long break.
Lea Alcantara: Yeah.
Emily Lewis: And got some time to see your sister.
Lea Alcantara: Yeah, I know. It was a lot of fun, and then those who follow me on Twitter or Instagram, you would had seen that I did do the Swing.
Emily Lewis: Oh yeah, that was right away. You did like your first day after landing?
Lea Alcantara: Yeah, pretty much. [Laughs]
Emily Lewis: This is scary craft.
Lea Alcantara: I did the Swing. Do you know the actual swing itself didn’t scare me? I mean, it did. At first, I wasn’t sure I was going to swing like I was just going to sit there, but then my family was egging me on.
Emily Lewis: [Laughs]
Lea Alcantara: And I’m like, “Okay, I’m going to go swing.” What scared me though was actually that tree house that was attached to…
Emily Lewis: The climbing to the chair.
Lea Alcantara: I didn’t come to the top.
Emily Lewis: Oh.
Lea Alcantara: I climb to the middle because it’s attached to the swing, it was swaying.
Emily Lewis: Oh. [Laughs]
Lea Alcantara: And it’s high, so it’s high and it swing and I couldn’t go all the way to the top. I just got to the middle part, and I was just like gotten help then.
Emily Lewis: [Laughs]
Lea Alcantara: Yeah, that was more scary than…
Emily Lewis: Fun. [Laughs]
Lea Alcantara: Than the swing. [Laughs]
Emily Lewis: Well, good. I’m glad that you bit the bullet and did it.
Lea Alcantara: Thanks.
Emily Lewis: You’ve conquered your anticipatory fear. [Laughs]
Lea Alcantara: [Laughs] Thanks.
Emily Lewis: All right, well, let’s get to some news.
Lea Alcantara: All right. So news in our world, there are just a few more days to submit your votes for the 2014 .Net Awards. If you love our podcast, hope you do and haven’t already, please take a few minutes to vote, so visit the thenetawards.com/vote. We’ll have a link in the show notes.
Emily Lewis: And conference season is in full swing, and we’re giving away a free ticket to upcoming events, Peers Conference and RWD Summit. If you’d like to attend Peers Conference this April 23rd and 25th in Washington, DC, follow us on Twitter @ctrlclickcast and send us an @reply telling us who are the female devs and designers that inspire you. We’ll announce the winner on our next episode which is out on April 3rd.
Lea Alcantara: If you’d like to attend the online RWD Summit on April 1st to 3rd, follow us on Twitter and send us an @reply telling us why you want to attend. Winner will be announced on Twitter on March 26th.
Emily Lewis: And lastly, we want to remind our listeners that we are sponsoring the weekly EE Help Chat with Arcustech. Join us every Wednesday at 3:30 p.m. Central to talk ExpressionEngine, web design and web dev, or just hang out. Follow us on Twitter to get the Help Chat link each week. Now, let’s get to news in the world of content management systems.
Lea Alcantara: Based on feedback from their survey, Perch updated its solution section which is a collection of work examples of how to use Perch. Not only did they add 20 new examples, but everything is also on GitHub. We’ll have a link to the solution section and the survey in our show notes.
Emily Lewis: As Christopher and Ari mentioned in our last episode, Environments for Humans is hosting the Craft CMS Summit, a full day online conference focused on Craft. The Craft Summit is June 17th, and we’ll have a link in our show notes.
Lea Alcantara: There has also been a few more Statamic learning resources released, live workshops during Peers Conference and another one hosted by Clear Bold. plus Jason Varga has written a tutorial on building a private photo site. We’ll have links in the show notes.
Emily Lewis: And there have been a lot of releases lately in the CMS world including Craft 1.3 and ExpressionEngine 2.8.1, so go and check those out, and as always, we’ll have links on the show notes.
Lea Alcantara: If we overlook news about a CMS you favor or are interested in, let us know, and we’ll get it on our radar for future episodes.
Emily Lewis: So today we’re talking about security audits and integration in ExpressionEngine with Matt Weinberg. Matt is co-founder and President of Tech at Vector Media Group, a New York City web development marketing agency. A renowned EE and e-commerce expert, Matt is both innovative and pragmatic. In addition to his focus on large publishing platforms and custom e-commerce stores, he leads Vector’s development team in delivering reliability, speed and stability in all projects. Welcome to the show, Matt. Thanks for joining us.
Matt Weinberg: Thanks for having me.
Lea Alcantara: So Matt, can you tell our listeners a little bit more about yourself?
Matt Weinberg: Sure. So as you mentioned, I’m president of development and technology at Vector. I co-founded the company many years ago. Actually, my partner and I started working together in middle school or high school, and we’ve just been doing it since. Now, we have 16 or 17 people in New York. We have amazing clients. I have an 8-month-old daughter. I live in the city as well, and basically, most of my time that’s not work is just spent at home with my daughter and my wife, and my dog who gets a lot less attention these days because of that.
Lea Alcantara: Oh.
Emily Lewis: [Laughs]
Matt Weinberg: Unfortunately for him, he used to be king of the house, and now he’s forgotten.
Lea Alcantara: Oh, poor baby.
Emily Lewis: Well, he’ll have a new best friend in a couple of years when your daughter is a little older. [Laughs]
Matt Weinberg: [Laughs] I hope so.
Lea Alcantara: So why don’t we dive right in. First things first, why don’t we just define what security actually is? What does it mean in general for sites?
Matt Weinberg: Sure. It’s a great question. We have a really wide variety of clients, and we have small startups that are like one person, and we work with also a bunch of like Fortune 100 companies as well, so we have a really wide range of clients, and I think security means something pretty different to all of them. In general, security is this idea that nobody should be getting access to your data or have the ability to make changes to your data without your permission, and that’s obviously a very, very wide definition.
In smaller companies, they’re mostly concerned about if people are going to hack our data or people are going to be able to get credit cards if it’s e-commerce, that kind of thing. With bigger companies, they are I think also even concerned about the backgrounds of our employees, the physical security in our office, and then beyond the client, again, is your data secure when you are transmitting it if you’re doing credit cards? If you’re doing it with passwords, are you storing passwords correctly? If you have SSL, is that set up correctly? What are the access restrictions on your infrastructure and all of that? It’s a pretty wide variety of topics.
Emily Lewis: And when you’re dealing with an ExpressionEngine project, is there anything unique to that particular platform that needs to be dealt with in terms of security?
Matt Weinberg: Sure. I mean, it depends. It depends on what you are comparing it against. I think that all prebuilt platforms and CMSs have their own benefits and challenges, and I think all custom-built platforms have their own benefits and challenges as well. So with ExpressionEngine, I think you get a lot of benefits. I think even though EE has had its security issues in the past, and I’m sure there are current security issues as well, I think there’s no way to avoid that. Every platform that’s ever existed in the world will have a security bug sometimes. I think that EllisLab has done a really nice job in the past fixing security issues and quickly identifying them. They’ve been very proactive, and then really importantly, a lot of the times when we are talking about security issues, we’re not talking about even core ExpressionEngine stuff, we’re talking about add-ons.
Lea Alcantara: [Agrees]
Emily Lewis: [Agrees]
Matt Weinberg: And so EllisLab has given add-on developers a lot of tools to help mitigate security issues, so with things like the Input class and a lot of XSS protection and all of that. It’s not everything. Add-on developers do need to be careful, and we find security issues in third-party add-ons constantly, but I think that EllisLab has done a really nice job trying to help people not shoot themselves in the foot, unlike I guess I’d say WordPress.
Lea Alcantara: Oh.
Matt Weinberg: WordPress has a lot of people who are on it, and I think WordPress is a great platform in many ways, but I think, in general, maybe it’s a popularity, maybe it’s just because there are a lot more add-ons or something, but you tend to hear about security issues there a lot more, and you tend to see a lot more poorly written add-ons sometimes. The major WordPress add-ons are good, but I think there’s such a long tail of just really poorly written WordPress add-ons that have a lot of security problems.
Emily Lewis: And so that general level of security within a system, is that one of the first things you focus on when deciding what CMS to use for a given project?
Timestamp: 00:10:01
Matt Weinberg: Yeah, I think so. I guess I would say, if we have doubts about our ability to secure a specific platform, we would not use it, even if it were the perfect feature match for our client, right?
Lea Alcantara: [Agrees]
Matt Weinberg: Because it’s not even worth consideration in that case. If we are even considering a platform, which in our case is typically ExpressionEngine, something custom on Laravel, or something custom on CodeIgniter, maybe a little bit of Drupal, we’ve probably vetted the security there first.
Emily Lewis: [Agrees]
Matt Weinberg: We very rarely would recommend something that’s perfect on a feature sense, but we think is terrible with security problems because you just don’t want to go down that path.
Emily Lewis: Do you ever have to have a conversation with a client about that if they came to you with, in their minds, a given software that they want to use and then you have to educate them about why you don’t want to move forward with that?
Matt Weinberg: I think it’s less about software with clients and more about features. We pretty often have clients asking us for features that are just nightmarish from a security point of view, and we push back. A couple of examples I can give you, a lot of times clients want to be able to send password reset emails or like password reminder emails that have the person’s plaintext password in the email.
Lea Alcantara: [Agrees]
Matt Weinberg: I’m sure you’ve gotten them before, “You password is matchdog12 or whatever.” [Laughs]
Emily Lewis: [Agrees]
Matt Weinberg: So like you can’t do that because if you’re doing that, it means that you need to be securing passwords, or it basically means you need to be storing passwords in a really insecure way. So that’s something that we have to tell clients. For us to be able to do this, it would mean that we’re building a system in an insecure way, and we’re not going to do that. We want to make sure we’re hashing the passwords and salting the passwords and encrypt or whatever.
Another good example is with credit cards. There are really good providers out there that will allow you to tokenize passwords, and I can explain what that means a little bit if you’d like, but they allow you to securely store credit card numbers so that you can charge those credit cards without having to store the number. A lot of our clients ask us, “Oh, why don’t we just store this? Or why don’t we just email plaintext password numbers to whoever in their front office who needs to process it?” I mean, you can’t do that. You can store plaintext credit card numbers and you can’t be emailing credit card numbers around because it’s insecure. It’s against PCI, and you’re opening yourself up for a lot of potential liability. I think it’s more of a feature point of view than in their framework point of view in that sense.
Emily Lewis: And Matt, I’m not familiar, what is PCI?
Matt Weinberg: Sure. I’m sorry about that. So PCI is a set of regulations and rules and guidelines that was formulated by the credit card industry. They basically guide you on what you need to do to secure a system. It’s based on a lot of things, but for instance, smaller companies who are doing processing less money in credit cards may have less stringent requirements than larger companies that are trying to store data, and it’s basically a set of regulations around what you need to do for security, how you store that information, how you transmit that information, and all of that.
Lea Alcantara: So I’m curious because you said, of course, it seems like common sense, we’re not going to have plaintext-emailed passwords and stuff like that, so what are your thoughts about the popularity of tools like One-Time Password to send, or now, was that One-Time Password or onetimesecret.com where you basically go to that site and you plug in some one-time secret and then you can send that link to someone and they can click on that link, and that link only works one time, and then you can no longer click on that link anymore. Is that secure?
Matt Weinberg: I don’t know them personally, the people behind this.
Lea Alcantara: Sure.
Matt Weinberg: And I haven’t inspected their code, but I would say, if you’re pasting plaintext into any website, even if they’re claiming to encrypt it beforehand, you just have to assume that the people running the website are going to have access to what you pasted in. Sometimes you see a web service and they go online and say, “Do this, paste in all your private stuff.” And they say, “Look, you can even inspect our code on GitHub to see how secure it is.” But you have no guarantees that the code on GitHub that they released as open source is actually what their server is running.
Emily Lewis: Right.
Matt Weinberg: So I would say, without saying anything specific about them because I don’t know them and I don’t know the people running it, if you’re pasting plaintext, even if it’s including the password into a site, you just have to assume the owners of the website are going to have access.
Emily Lewis: Now, let’s talk a little bit about security audits, what is a security audit? What’s involved?
Matt Weinberg: Good question, so a lot of our larger clients, I would say all of our Fortune 100 clients, usually request that we go through a security audit before we do any work for them. Sometimes that security audit is part of the sales process, so they won’t even consider giving us the project until we’ve passed it. Sometimes that security audit is after we have the project, but before we can start writing code, and then it’s more of a company who process this audit, and sometimes that audit is during development, and they audit a number of things.
First of all, they audit our processes. They want to understand how we deal with storing code, how we deal with storing private information, and I’ll talk about private information separately because that’s a little bit different, but how we do with storing our code, how do with deployments, who’s hosting the website, where would that hosting be, who’s responsible for the security there, are there firewalls, are there measures in place to detect intrusions, are there measures in place to log intrusions, and not only are you detecting the log-in, but are there measures in place to actually deal with logged intrusions.
A lot of companies put logs up on servers, but they don’t actually have any process to go over those logs every so often and detect if there’s something actually happening that shouldn’t be and resolve it. They want to know who at your company is responsible for those things. Do you have a chief security officer? Do you have someone in the tech team that’s responsible for security companywide or is it more project by project?
Then on the personal information side, they want to know who’s going to have access at our company to their client’s data, and that could mean registration data for our client’s users. They want to know how we store their information, what service is it going to be on. If it’s encrypted, where is it encrypted, how is it encrypted? Is it encrypted by the application? Is it encrypted by the database? Do we use real data on staging? Do we keep real copies of real production data locally on development environments? Are we backing it up? All of that.
Then you get into actual code audits where we’re getting security scans. We’re getting what’s called fuzz. We’re getting penetration tests. They want to know who run those tests, and then a lot of times our clients will actually have their own security operations departments that want to run those tests too, and they run all kinds of security scans and auditing against our code. They also want to know what our processes are for deploying new code. Do we rescan repenetration tests when we’re doing deployments based on new features?
Emily Lewis: So for, I guess, all of these different areas where security audit may be involved, is it something where there’s like a form that you fill out in a checklist? Are you working one on one or a team with the client going through these questions and then sort of going in and validating? What sort of the relationship of them getting the answers to these key questions?
Matt Weinberg: So again, I would separate which questions we’re talking about. The first set of questions is usually just the processes company type questions, again, who’s responsible for security, who’s responsible for deployments. They want to know a lot of times about physical security at our office. Is it locked? Are there key cards? Are computers locked? What’s the backup situation? They want to know if we have a wireless network, and if that wireless network is physically separate from our wired network, and how we control access to it. That’s usually is a form, and some of our clients have literally online portals where you fill all of that out, and sometimes they’ll just email it to you as an Excel spreadsheet or Word document. That’s generally in a form.
The code audit or the security audit part is typically not in a form because that’s typically, we need to put our code on some kind of staging server somewhere and let them run their tools in there.
Emily Lewis: [Agrees]
Matt Weinberg: And basically, we let them try to hack it after we’ve done our testing.
Emily Lewis: Cool. Now, a lot of these things sound like it lets the client know in advance what they’re dealing with, so it has a lot of benefit to them. Is there any benefit to these different audits for you as a company? Like do you learn lessons from each audit and sort of integrate it into future projects?
Matt Weinberg: Absolutely, absolutely. These audits, the first time we did when I thought it was just a giant pain, I was like, “Why don’t I need to fill out a 30-page document about the physical security in my office?” [Laughs]
Lea Alcantara: [Laughs]
Matt Weinberg: And I was a little annoyed by it, and that was a couple of years ago, and then I realized, “You know what, it’s legitimate. If we want these kinds of clients, if we want big projects, they’re dealing with a lot of data, these are good questions that they’re asking.” The questions they’re asking might expose some weaknesses in our process too, and first of all, I’d say that from a process point of view, we’ve gotten a lot of benefits. We’ve had clients ask certain things and we’ve actually said, “You know what, we don’t do that, but that’s a great idea, and we’re going to start doing that for your projects, and we’re going to do that for all of our projects.”
Then on the security side, I don’t think there’s any piece of software out there that is entirely bug free or security hole free, right?
Lea Alcantara: Sure.
Matt Weinberg: Like there are software programs out there that have been out for decades and decades and you still find security problems, so I don’t think anybody could promise that, but every time that a security problem gets exposed, “Well, that’s another thing. You know what, that was a mistake we made.” Maybe that’s a process mistake, but we didn’t test it well enough. Maybe that’s a coding mistake where we made a mistake in our code. Maybe that’s a testing mistake where we need to enhance our own test suites so that kind of thing never leaves our development, our local development. So we’ve learned a lot of lessons that way, and we’ve certainly been introduced to security attacks of the type that we’ve never even heard of before, but are legitimate attacks that people could be running or Bad Actors could be running on all of our sites at any time. So we’ve learned a lot from this process. Unfortunately, sometimes I’m learning because it’s 2 a.m. and I get a phone call from a client’s security operations team. [Laughs]
Lea Alcantara: Oh no.
Matt Weinberg: But that’s pretty rare. The one thing I’ll say is that, I think what it has helped us do on some of these projects is it helped us put into place a much better prereleased security testing infrastructure. So now, we have manual tools and we have automated tools, and we know what to scan and how to scan and where to scan and what to try before we actually release anything to the wild and to our client’s security team.
Timestamp: 00:20:07
Lea Alcantara: Well, it sounds like it’s a very comprehensive type of process to do all of this, and you mentioned earlier that you have a variety of clients from the Fortune 100 to a tiny small business. So would you go through this process as well for that tiny small business, or do you have an altered process?
Matt Weinberg: We would go through the entire code security process for our smaller clients. I think that you cannot cut security from a budget, you know?
Lea Alcantara: [Agrees]
Matt Weinberg: If a client has a small budget, then that’s maybe you need to relook at features or look at other things, but you can’t say, “You know what, it’s easier to allow SQL injections or whatever.” [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Matt Weinberg: No, you can’t….
Lea Alcantara: Yeah.
Matt Weinberg: You can’t do that because you’re exposing your client to a lot of issues, a lot of potential issues. It’s not good. You really have to have zero tolerance for that stuff inside of your organization, and our team takes SQL injection, XSS and all of that just kind of stuff really seriously, and if you start on any project saying, “You know what, it doesn’t really matter,” it starts a bad habit. Do you know what I mean?
Lea Alcantara: [Agrees]
Matt Weinberg: Because then you start saying that. When you’re time conscious, you start saying that for everybody. So I would say that we really don’t cut corners on any sized clients for that. But of course, smaller clients, they don’t ask for us to fill out 30-page audits about our physical office security, you know? [Laughs]
Lea Alcantara: Sure. [Laughs]
Matt Weinberg: We don’t do anything like that.
Emily Lewis: I’m sorry to interrupt, but I’m just curious, you mentioned that you’ve established, I guess, like a security infrastructure. These are processes that you follow to address the things that you’re talking about like XSS, SQL injections. Can you give us and our listeners a few examples of what is involved, or like what’s included in that infrastructure?
Matt Weinberg: Sure. Actually, do you mind if I just back up for one second?
Emily Lewis: Yeah, sure.
Matt Weinberg: One other thing I’d add is that sometimes there are steps, security steps, we need to take that are important to a specific client, but might not be generally applicable. So we have one client that we’re working with right now. It’s a very well known brand, and they have an internal security standards that around encrypting in the database level. So you can’t have any unencrypted data in your database at all if it’s what’s called PII, Personal Identifiable Information, and every company’s definition of PII tends to be pretty different, but this company, they felt basically anything is PII. A username is PII. Login information, not passwords, but list of login time or anything like that is PII. So basically, they require that we encrypt, it’s what called “encryption at rest,” in the database. So if we’re going to load a database backup, literally all of the information and all the data will be totally encrypted, and we have to handle that in our application, so our application, before we insert any rows or update any rows, we encrypt all the data, insert it, and then we have to decrypt it on the way out.
Smaller clients and even big clients may not care about that. We have a lot of big clients that don’t care about “encryption at rest” and don’t want the potential performance penalties with that kind of thing. So I wouldn’t say that’s us not doing best practices for all of our clients, but I would say that some clients have different needs.
Emily Lewis: That make sense. So in terms of what sort of the basic things you do to help ensure that you are preventing attacks, what are some of the tools you use or processes you follow internally?
Matt Weinberg: First of all, I would say use your framework or CMS’ Input classes. ExpressionEngine has a great Input class. Laravel has a great Input class. CodeIgniter has a great Input class. You really shouldn’t be dealing directly with GET and POST and things like that directly unless it is done through your applications Input class first. Another thing is don’t try to write your own security. There are tons of existing open source libraries that are either part of your framework already that have been tested way better than anything you could test. You should never try to write your own password hashing algorithm. You should never try to write your own anti-XSS stuff, and if you do that, if you just trust what’s in there and make sure that you consistently use it, that fixes 90% of the common issues, so that’s the first thing that’s on our list. We just make sure that when we’re coding something, we’re using the built-in Input classes, or we’re using the built-in XSS. We’re using the built-in password hashing and all of that.
Taking it to the next level, we have tools that we use, and Burp Suite is certainly one of them. SQL Map is certainly another one of them, and there are a couple of internal tools we have as well, and that’s around automating. So in those cases, you can point it at a form or point it at a URL, let it try to do some automated SQL injections and all of that. That’s part of our suite of tools as well, and another thing is what we do is we make sure we’re using the built-in templating language escaping, so one common vulnerability that you see all the time is people allow user-inputted data to be directly output to a template, like in ExpressionEngine terms, you’d collect the Freeform data and you’d output it directly, and if you’re not HTML escaping that, you can be opening yourself up to a type of attack called cross-site scripting. So make sure that you’re using your framework or language built-in escaping tools. Don’t try to write your own regex or anything. Use the PHP one. Use the ExpressionEngine one. Use the Laravel one. When you’re using Python, there are some great templating tools out there that have escaping on. Is that what you’re asking?
Emily Lewis: Yeah, absolutely, yeah. Thank you.
Lea Alcantara: Well, do you use any third-party services on top of the current internal items?
Matt Weinberg: I wouldn’t tell you services, but we certainly use third-party software.
Lea Alcantara: Okay.
Matt Weinberg: Burp Suite is one piece of software that’s very, very widely used in just the security industry, its penetration testing and all of that. SQL Map is another one. SQL Map is a great tool that allows you where you can literally point it to forms. You can simulate GET and POST request, and it will try to figure out as much as it can using basically SQL injections about your underlying infrastructure, and people might be saying, “Well, I escape all of my input coming from SQL so it’s not a problem.” And that might be true, but you might be exposed to other attacks or something called a blind SQL injection, and that can be tested for, and there are a couple of others, so we use that and generally throw that against our forms to make sure that we’re not vulnerable to that.
Emily Lewis: I’m curious, a lot of the things you’ve described, they sound like they take some time, and I guess I’m aiming this question a bit when you first started being very detailed with your security and you were first getting these audits from clients. Did it have a big impact on the time and cost of a project, and has that stayed the same over time as you’ve gotten more adept at it?
Matt Weinberg: It’s definitely gotten more efficient as we’ve done it more. The first times that we had to do things like this, you don’t really know and it took a lot of time. I’d say these days, it’s not a significant portion of our project’s budgets. It’s not something that we have spend weeks and weeks and weeks on, you know?
Emily Lewis: [Agrees]
Matt Weinberg: You can save yourself a lot of time by making sure that you are developing those best practices. So what you don’t want to do is develop the site insecurely and then test it later because then you are going to be spending weeks and weeks fixing things.
Emily Lewis: [Agrees]
Matt Weinberg: But if you have a really good culture in your organization of building things securely and testing things then and letting other people review it, it makes your job at the end easier because typically you’re going to avoid a lot of issues during the build process.
Emily Lewis: And is it something that you build into your proposals to win projects, your emphasis on security and your protocols?
Matt Weinberg: It depends. If the clients are big clients that is going to have a security operations team, then absolutely, we’ll mention it upfront. We’ll talk about it. Generally, you don’t honestly ask about it, and again, they’ll ask about our processes as well, who has access to data, who controls data, are we using two-factor authentication, et cetera, et cetera. With small clients, you don’t have to mention that we use best practices, but a lot of times they’re not very technical, and if we start talking to them about SQL injections and cross-site scripting and all of that, then they kind of glaze over, and I think a lot of times also small companies or small clients, they’re trusting you. They’re hiring you because they trusted you’d do these best practices, and so we’re doing them that because like we’ve promised it in the sales process per se, but we’re doing it because we promised them that we’d do right by them and build them a quality piece of infrastructure, and if we’re not doing that on the server level, we failed for them. I wouldn’t say we’ve failed for them, but we’re not necessarily doing best practices for them.
Lea Alcantara: So I’m curious then when you’re building in security or pitching in security, et cetera, how much can you actually guarantee to a client even with an audit? Like how much responsibility do you take if/when something happens?
Matt Weinberg: You can’t guarantee it. I mean, first of all, Black Hat, Bad Actors, there are many more of them than there are of us.
Emily Lewis: [Laughs]
Matt Weinberg: And they are much more financially incentivized to find exploits than most developers are to fix them, you know?
Lea Alcantara: [Agrees]
Matt Weinberg: And that’s a problem, and it’s just something that’s unavoidable because it’s you and your development team against literally any Bad Actor on the internet who just constantly scans sites, and you can’t guarantee your clients anything. You just can’t. As much as they want to see it, it’s just the example I went back to before. If we could do everything right, every best practice in the whole world, and some new kind of exploit might be discovered tomorrow that we’re vulnerable to, that we’ve never even know about, you know?
Lea Alcantara: [Agrees]
Matt Weinberg: Every piece of software has bugs. Every piece of software has security holes. Look at Google, Google has a huge security operations team that’s always, always posting online and talking about everything they do, and those are I’m sure some of the smartest guys out there, and they still have a bug bounty program because they get exploited constantly. So I would say that if a client gets exploited, it’s something that we try to deal with as soon as possible and try to fix it for them and try to learn how it happened, but you can’t really guarantee. You can’t guarantee to a client that they’re never going to have a problem.
Emily Lewis: Now, this is a more business money question, but if a client comes to you and maybe it’s been three years since you launched their site and maybe you’ve been doing some maintenance work here and there, some major security breach happens and of course, you’d fix it. Is that something that’s sort of like a warranty for your original project, or you do bill them for that additional work to fix something that came up?
Timestamp: 00:30:03
Matt Weinberg: Yeah, I mean, just in general, we bill everything hourly in our projects, even at the end, and we tell clients they should budget some for post-launch type work, so we will just bill everything hourly anyway. I get what you’re saying. A client might say, “Well, you told me you’d build this, and you built this properly.”
Emily Lewis: Right.
Matt Weinberg: But you hope to have clients that understand that we are a services organization. We did the best we can. We did probably a lot more than a lot of other companies would do, and exploits are just kind of a part of doing business. As I said, the biggest companies in the world that have just major dedicated security operations teams, they still have security problems.
Emily Lewis: [Agrees]
Matt Weinberg: So you hope your client understands that.
Lea Alcantara: Let’s bring it back to ExpressionEngine. Earlier you mentioned that some of the issues are dealing with third-party add-on security. With that in mind, can you tell our listeners how to fix that? What are the most common third-party security holes that should be patched?
Matt Weinberg: Yeah. First of all, if you find this security hole in the third-party add-on, you should submit it to the add-on maker immediately like, “Patch it on your side,” and then submit a diff to the add-on maker.
Lea Alcantara: [Agrees]
Matt Weinberg: We do that. We’ve emailed a lot of add-on makers and just basically said, “Hey, this is a problem here, you need to take a look at this.” And they fix it. I’ve never had an add-on maker say to me, “Oh, this is nonsense. I’m not going to fix this.”
Lea Alcantara: [Laughs]
Matt Weinberg: I think all of them are happy to be getting security audited by dedicated security operations teams. Yeah, I mean, I think that you have to worry most, first of all, about add-ons that are taking user input.
Lea Alcantara: [Agrees]
Matt Weinberg: So it does not even talk about the admin, the control panel, for a second, but if you have an add-on, I’ve never found an issue in Freeform. I’m just going to use Freeform as an example in ExpressionEngine. Like Freeform takes user input, deals with user input, and outputs user input, and so an add-on like that is going to potentially have security problems. Again, I’ve never seen anything like that in Freeform. It’s just an example. So that’s where you have to be careful, first of all, with add-ons that are interacting with the user in some way, like are they taking input? Are they getting parameters from query strings? Do they have action URLs? You have to worry about that stuff.
The other thing you have to think about is what’s your trust model for admin users. If you feel like you can totally trust anybody on the admin side, then things are a lot easier because we’ve seen a ton of security problems with the control panel interfaces for add-ons, and we’ve submitted those to add-on developers, but we may on our side not see those as a priority one threat because our trust model for that particular client is that if you have a properly authenticated session on the admin side, we basically trust you effectively, and we do that in a couple of different ways. On a couple of clients, we’ve rewritten some of the ExpressionEngine authentication stuff to have a better security model based on what they needed.
But if you can’t trust people on the admin side, then you have to worry about any add-on that has module interface and extension interface or anything like that, because, I mean, then you have tons of problems. We’ve seen people, add-on makers, that use the Input classes on the front end, but not on the back end because they figured, “Whatever, it’s the control panel, who cares?” But that could be a major problem. You could have someone who’s only authorized to be an editor, but suddenly they’ve taken control of the whole system. Again, if you feel like you can trust your editors or your non-super admin users, that’s less of an issue for you.
Emily Lewis: Now, is there anything that is unique about ExpressionEngine that makes it particularly good with just fundamental security, with the platform?
Matt Weinberg: First of all, I think EllisLab certainly, they take security seriously. I think if you were to submit a security issue to EllisLab, they would fix it very quickly, and I know that’s certainly the case of a lot of open source tools as well. You could fix it yourself or submit it to them, or do a pull request or whatever, but there are some other commercial applications out there where the sponsoring organization or the owner is not quite as responsive as EllisLab, so that’s one thing that ExpressionEngine is certainly has going for it, and it’s something that we mention whenever we’re trying to pitch to clients on ExpressionEngine.
The other thing is it’s a pretty mature product, and it’s been looked over a lot. It has gone through security audits by us. It’s gone through security audits by lots of other people. You see people online talking about security audits, so it’s had the opportunity to go through a lot of different audits and fixes and all of that, so I think a low hanging fruit is probably not there on ExpressionEngine.
Emily Lewis: [Agrees]
Matt Weinberg: It’s probably more complicated stuff at this point.
Emily Lewis: Now, how about ExpressionEngine’s security and session preferences? And I bring this up because we had a listener on Twitter who asked us. Andrew Fairlie had a question about cookies in sessions or cookies only. If you could address that question, but then also maybe talk about whether developers should be making modifications to those preferences for new builds?
Matt Weinberg: Sure. So I don’t necessarily think that cookies only versus session IDs only or the mix, I don’t think one is necessarily better than the other. I think again it’s about your threat model. I think before when you’re doing a project, you have to understand what are you actually trying to protect against here, and ExpressionEngine does a pretty good job of explaining the pros and cons of each approach. Like if you just have a session ID and authenticate through that versus if you have a cookie versus it even has a preference about it if you wanted to check, check like browser, user/agent strings against the logins so nobody can spoof your cookie or anything like that. I don’t think one is necessarily more secure than the other, but I think that if you read the differences between them, you can understand what fits better from a security point of view for your specific client. Is your client going to be logging in from a number of different places? Are they remembering me? Are they doing the “remember me” login? All of that. Big mistake that people make is that they give their client one admin username and password and just have their client share that amongst their like 20 employees, and that’s a big problem.
Lea Alcantara: [Agrees]
Matt Weinberg: Because, first of all, if they fire somebody or they hire somebody, they’re suddenly sharing this password, then you have trouble auditing what people are doing, and then you run into issues with sessions and people. Like there’s a bug in EE up until its recent release where you have to keep on logging each other out. I think it was cookies only because we would like check this or this IP address and all of that. So I think as long as you have different logins for all of your client’s employees, and you understand the threat model and you understand the differences, I don’t necessarily have a preference with those.
Emily Lewis: And so do you make any changes to the default settings for security and session preferences for your ExpressionEngine projects?
Matt Weinberg: That’s a good question, I actually don’t know what the default settings are because we have a prebuilt sandbox that we just start all of our sites on. I could see what that’s set to. I don’t know if you were to download EE from scratch these days, what it would default to, to be honest with you.
Lea Alcantara: So we’ve talking a lot about the technical aspects of securing a site, and I think you kind of touched on this about like do you trust your admins and things like that, but sometimes the best security can be thwarted simply through social engineering. So does Vector Media take some of those things into account with a security audit and how you secure your site, or recommendations you give to your client?
Matt Weinberg: Yeah, of course, I mean, first of all, at some point you’re going to run into the human thing like you do as you’re saying.
Lea Alcantara: Yes.
Matt Weinberg: You can do everything you can on the code side. You can make everything super secure, but there are humans involved, and humans have flaws unfortunately for all of us.
Lea Alcantara: Sure.
Matt Weinberg: So I talked before about not allowing clients to have access to password, plaintext passwords. I called up one of our client’s hosting providers the other day and I was trying to get some information. I was on the phone with their support, and they said, “I just need to authenticate you. Can you tell me the account’s password?”
And I said, “Really? Like you’re a hosting company and you’re asking me to, first of all, tell you the account’s password?” I said, “If I were to tell it to you, do you need me to spell it slowly?”
And he said, “No, no. I’d just compare it to what I see on the screen.”
I said, “That’s crazy. It’s crazy that you can see a plaintext password on the screen, and it’s crazy that you’re asking me to read you my password out loud.” You know?:
Lea Alcantara: Yeah.
Matt Weinberg: That’s not secure. So there are certainly technical steps you can take to prevent people from doing that, but at some point, again, you have to ask how much can I protect people against themselves, and sometimes the most secure thing that you would do for people is prevent them from doing legitimate business activities. Not that this hosting thing was illegitimate because that was crazy that they asked that. But there are other things, some of our clients are concerned about, as I said before, with personal identifiable information. So they say, “Well, people shouldn’t have access to personal identifiable information unless they’re authorized.”
Well, you say, “Well, you know what, this client has a business need to go and be able to change people’s email addresses when they get customer support inquiries and read their name and see some of their activities that can help on a customer support side.” So you have to balance that. Unfortunately, sometimes it just means a lot of training to the people that have admin.
Emily Lewis: [Agrees]
Matt Weinberg: I don’t know if that answers your question fully, or if that was a good answer, but it’s something that we train clients too. We make sure clients understand what the threat risks are, and that they’re authorizing their minimum level of admin access as necessary. Another good example is even if we give them super admin login information, we would generally also make a lesser admin for them and tell them to use that day to day.
Emily Lewis: [Agrees]
Matt Weinberg: Like for their main, they shouldn’t be using a super admin login to publish a new blog post, you know?
Lea Alcantara: Yeah, yeah.
Matt Weinberg: Or even necessarily to register a new member. Like keep that super secure password, put that to the side. If you ever need that for whatever, it’s fine, but day to day, use your less privileged user.
Emily Lewis: Now, before we finish up, is there some overarching advice you could give to someone to help them build a site in a more secure fashion?
Matt Weinberg: In the sense of just kind of any or just generic site or…
Emily Lewis: Honestly, I can say that I don’t feel like I’ve necessarily built all of my projects in the most secure fashion. I’ve tried to follow the best practices, but maybe someone like me who’s not really sure what would be one of the first steps I could do for my next project.
Matt Weinberg: Let me ask you a question, when you say you haven’t built them in the most secure way, now what does that mean? Do you just mean you haven’t thought about it, or are there something else?
Emily Lewis: Well, it’s not something I thought about beyond going through something like the security and session preferences, but I certainly don’t do any of the coding tests that you mentioned for cross-site scripting and SQL injections, so it makes me feel that maybe some things could be insecure, like I haven’t done any testing.
Timestamp: 00:40:04
Matt Weinberg: I’ll just talk about ExpressionEngine for a second here, but what I’m going to say applies to anything. Remember that any ExpressionEngine add-on has access to your entire database and all user input that goes into the system. So even if you have the tiniest little plugin, if that plugin tag is running on a page, it’s going to get access to every GET and POST request on everything, and it could potentially do anything at once to your database. It could read everything. It could send. It could read your whole database and send all your contents in an email, even the most innocuous-looking plugin. So the first thing I would say is don’t download random plugins and extensions and modules before you’ve either looked through the code or if you haven’t looked at the code, get somebody that you know that can look through the code or get things from trusted developers, right?
Lea Alcantara: [Agrees]
Matt Weinberg: Solspace is not going to intentionally delete your whole database and email the contents to them, and Pixel & Tonic is not going to do that, and Low is not going to do that, and DevDemon is not going to do that. So be very careful when you download these little add-ons from Devot:ee, that even if they look small, literally there’s no permission that’s in place. Once you install that extension, it can literally do anything at once. It’s just the first step, and by the way, the same thing applies really to WordPress and Joomla and a number of other systems, be very careful with what you’re installing.
The second thing is, again, I don’t know if you’re writing custom add-ons or anything like that or custom PHP, but if you are, use what’s built into ExpressionEngine. Use the Input class, use the XSS, use the Sanitizer, all of that, before you do anything because a lot of work has gone into those, and don’t ever try to write your own security, like never try to write your own password hashing algorithm. I mean, for fun, sure. [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Matt Weinberg: But never in production. Don’t try to write your own Sanitizer. Don’t try to write any of that. There’s stuff that’s out there that’s been tested, that’s known to be good.
Lea Alcantara: Awesome. So that’s a lot of good advice, but before we finish up, we’ve got a rapid fire ten questions so our listeners can get to know you a bit better. So are you ready?
Matt Weinberg: I hope so. [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: All right, first question, Mac OS or Windows?
Matt Weinberg: Mac.
Emily Lewis: What’s your favorite mobile app?
Matt Weinberg: Oh, you know what, I love this app called Captio because I use my inbox as a to-do list, and Captio just preprogram your email address. When you open it up, write up a quick note and hit send and it will automatically emails it to you with the subject line and everything.
Emily Lewis: [Agrees]
Matt Weinberg: It seems silly, but you save a lot of taps when you’re composing it, entering your email address, subject and all of that. It’s cool.
Lea Alcantara: Well, Emily, I think you’d like that.
Emily Lewis: I know, that’s us. [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: Like that’s got my name written all over it. [Laughs]
Matt Weinberg: Yeah, I use it all the time.
Lea Alcantara: All right, what is your least favorite thing about social media?
Matt Weinberg: It’s such a time suck, right?
Lea Alcantara: [Agrees]
Emily Lewis: [Agrees]
Matt Weinberg: Like I hate that I feel guilty when I have not been on Twitter for a week. I try to spend a lot less time, and you get this guilt like, “Why am I feeling guilty about it? This was supposed to be for fun.” You know?
Lea Alcantara: [Agrees]
Matt Weinberg: So I really hate that.
Emily Lewis: What profession other than your own would you like to attempt?
Matt Weinberg: Oh my, man, it’s to be like an electrical engineer. I think that would be awesome. I have a lot of fun with that kind of stuff, building things.
Lea Alcantara: Cool. What profession would you not like to do?
Matt Weinberg: [Laughs] Kindergarten teacher.
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Matt Weinberg: My sister is a kindergarten teacher, and she has the patience of a saint, and I have a lot of respect for her, and I just don’t think I’m made for that. [Laughs]
Emily Lewis: Who is the web professional you admire the most?
Matt Weinberg: Some of the people, some of the security people in our client’s organizations. They’re very serious about what they do. They spend a lot of time protecting, and if you’re a security engineer of a big company, but you don’t get known unless it’s for bad things, right? Like nobody respects what you do until there’s an intrusion and then you’re like, “Why didn’t you do better?” So I have a lot of respect for those kind of people, and then separately, I have a lot of respect for Ryan Irelan actually, who I think is super smart.
Lea Alcantara: [Agrees]
Matt Weinberg: He has a lot of great work for the community. He’s done like a great work for ExpressionEngine. He really know what he’s talking about, and I’ve had a number of conversations with that guy that were just really insightful to me.
Lea Alcantara: So what music do you like to code to?
Matt Weinberg: I put on the 80’s pop Pandora. [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Matt Weinberg: The Pandora 80’s pop station, and I just leave it on. [Laughs]
Emily Lewis: Awesome. What’s your secret talent?
Matt Weinberg: Oh no. I don’t have one.
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Matt Weinberg: Oh, I am very good at eating matzah, which I’m getting crumbs all over, which is like a very hard thing.
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Matt Weinberg: If you had matzah, you would realized it. I don’t know you’ve had matzah, but it’s like a very crumbly kind of messy experience.
Lea Alcantara: [Agrees]
Matt Weinberg: So it’s been almost three decades of matzah eating for me. [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Matt Weinberg: So I kind of like getting there.
Lea Alcantara: Nice. So what’s the most recent book you’ve read?
Matt Weinberg: Oh God, I have an 8-month-old daughter so I guess ¿Dónde está Spot? [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: Awesome.
Emily Lewis: Lastly, Star Wars or Star Trek?
Matt Weinberg: Truthfully, Star Trek, but I get made fun in my office for that, so Star Wars, I guess.
Lea Alcantara: Oh. [Laughs]
Emily Lewis: [Laughs]
Matt Weinberg: [Laughs]
Lea Alcantara: Flip hopper.
Emily Lewis: [Laughs]
Matt Weinberg: [Laughs]
Lea Alcantara: So that’s all the time we have for today. Thanks for joining us.
Matt Weinberg: Now, thank you for having me. I really appreciate it.
Emily Lewis: We do as well. In case our listeners want to follow up with you, where can they find you online?
Matt Weinberg: So my Twitter handle is @mrw. My email address is [email protected], and I encourage anybody to email me, tweet me or anything at anytime.
Emily Lewis: Great. Thanks again, Matt. It was a pleasure.
Matt Weinberg: Thank you.
Lea Alcantara: [Music starts] We’d now like to thank our sponsors for this podcast, Peers Conference and Pixel & Tonic.
Emily Lewis: We also want to thank our partners, Arcustech, Devot:ee and EE Insider.
Lea Alcantara: And thanks to our listeners for tuning in! If you want to know more about CTRL+CLICK, make sure you follow us on Twitter @ctrlclickcast or visit our website, ctrlclickcast.com.
Emily Lewis: Don’t forget to tune in to our next episode when we will be talking about Sass workflows with Ben Frain. Be sure to check out our schedule on our site, ctrlclickcast.com/schedule for more upcoming topics.
Lea Alcantara: This is Lea Alcantara …
Emily Lewis: And Emily Lewis.
Lea Alcantara: Signing off for CTRL+CLICK CAST. See you next time!
Emily Lewis: Cheers!
[Music stops]
Timestamp: 00:46:09
