 Good morning. I'm John Kebler, Mike Cooper over here. This is Hack the Textbook, which we're going to talk about the Textbook Security Project. We had hoped to be fully up and running, but we are in beta mode, so this is going to show you where we hope to be in a couple of weeks. Now, I'm going to go through real quickly a little bit about the problem we're trying to fix and a little bit about the project itself and do a little quick demo. Now, as we're all, you know, security aware, let's face it, other than the people problem, the majority of our security issues are caused because our code sucks, period. And why does our code so bad? Well, because most people that have learned to program in school have learned through textbooks that teach bad programming practices. They teach you how to write insecure code. If you, you know, try to fix the problem, you know, there's all sorts of problems with academia. And, you know, instructors have to teach what's in the textbooks because that's what they're evaluated on. There isn't time, you know, to try to fix the material. So there's a whole lot of excuses as to why there is a problem. And the goal of this project is to hopefully publicly disclose, you know, the vulnerabilities that are in textbooks to try to force the authors, you know, to realize that they do have problems and their problems have impact and that, you know, they need to be fixed. You know, from the industry perspective, you know, people expect when they hire a computer science graduate out of school that they want to have somebody that can write good quality code. And they're tired of having to retrain new graduates to be able to write secure code. However, from academia, they say, well, you know, it isn't a real problem. You know, if it was a real problem, the publishers would be pushing the authors to fix the books. And, you know, the students, you know, should be learning theory anyway, you know, not practical real-world applications. And there's also the argument among those professors that would like to fix the problem, that there's not enough resources to fix the problem. You know, half the instructors teaching software development are not security experts. And besides, the classes are so jam-packed anyway, there's not enough time to add new material to the courses. So that's the goal of this project, the textbook security project, which is also known as Hack the Textbook. The immediate goals are to publicly expose the security flaws in the most popular textbooks used in college curricula and to encourage authors to use secure software development practices in their textbooks, revise their existing books, and to get it right the first time when they write new books. The long-term objective is really to make secure software development practices the standard way that programming is taught across the academic environment, to make a security and integral part of every part of the computer science curricula. You know, right now, most people don't take a software engineering or a security course to their junior or senior. By then, they've had two to three years of learning how to do it wrong, and you expect them to, you know, in one semester, relearn how to do everything right. You know, that doesn't quite fit, so, you know, teach everybody to do it right the first time. And also, we'd like to become a resource that authors and college faculty can use, you know, to find out what are the latest issues and, you know, what are the problems and how should they be fixed. What we need is your help. You know, we need you to identify the textbooks that are out there in common use, the courses that are being, that they're being used for. We need people that are, you know, technically qualified, shall we say, you know, they have the creds in the industry to review the books. We need help, you know, editing the reviews because we want to make this, you know, professional because that's the only way we're going to, you know, get academia and the publishers to pay attention to us. Once reviews are up, we want to have people linked to the site, linked to the reviews. You know, somebody's got a really bad textbook out there. The only way that that fact is going to come to light is if the review is, you know, relatively high up in the Google search. We'd like people to contribute, you know, white papers that, you know, show best practices. And also, completely unrelated to the project, you as an individual working with your local university can say, you know, I am an expert in security. You know, these are the issues we're seeing in the real world because most in academia haven't a clue what is really going out there and they really don't even know that they're teaching bad software development practices. So, you know, you can work with your local universities, you know, to try to fix their problems in their curricula. If you have any publishers out here in the audience, we'd like, you know, to get contributions of books for review. And we're also going to set this up as a nonprofit corporation. So, you know, any other donations that we can get, you know, to help fund the project would be appreciated. There are several different levels of users. Basically, everybody just visiting the site will be able to review all the technical content. If you want to make a submission but you don't want to have to disclose any information, then we just ask for a one-shot email address that will send you a confirmation link just so we have a way of, you know, confirming that there's a real warm body submitting content out there. You can register providing some basic information such as your name and an email address. And you can, in that case, only the handle that you provide will be publicly disclosed. And you can submit books for review. You can comment on reviews. And you can assign books to courses that, you know, I'm using this book at this course at this school. And reviewers, you know, we would like for you to submit a brief bio so that when the publisher says, you know, who's this moron that's criticizing this book that we put out here, you know, we can show a bio that says, you know, this person is really somebody that knows what they're talking about. You should be listening to them. The only thing that would be disclosed publicly would be your handle or your real name, whichever you would choose to have disclosed. Your bio would be viewable by confirmed authors and publishers of the textbooks you review. It would not be viewable by all the publishers or all the authors, just the ones for whose books you've reviewed. And you would be able to do everything that a normal user could do, plus submit reviews and contribute white papers. We also have a need for editors to help go through and review content. You would essentially be invisible to everybody except the reviewers and the staff. And authors and publishers, we would require registration and then direct contact information so we can really verify that you are who you claim to be. And you would be invisible to everyone except the reviewers and the staff. A little bit of notes on workflow. Most of the content will not be made public until it's been reviewed and approved with exceptional book submissions and course submissions. Users that are not logged in will be requested to give an email address to confirm who they are and click on the link before the review contents made public. Editors may contact reviewers about making grammar and other clarity type corrections to your reviews. And authors and publishers can request that you contact them regarding your reviews. We will not disclose your contact information to authors or publishers, but we will inform reviewers that an author or publisher would like to talk to you. So please, let's keep professional. Don't make broadsweeping generalizations if you should choose to write a review. This book stinks. It does not construct a constructive review. Kind of stick to the facts. And we're going to go through now real quick demonstration. Mike? Thanks. A little display issue one second. All right. So basically I'm going to go add a book to the site and then we're going to add a quick review. A little bit of background while I was out at RSA earlier this year. Fortify talked about a book that they found had security vulnerabilities they contacted the author. So since they decided to pick on them a little bit, then we thought it was safe ground. So I'm searching for the book in Amazon's web services. So I'll bring that up and just confirm. This is the book that we want to review. We'll add it to the site. And then what we'll do is we'll go and add a review. I've already got some text. So I'm going to select the lowest rating for this book. I should caveat that this book does mention security in a little bit, but it doesn't actually talk about it in reference to coding. So let me get my review here. So as I mentioned that Fortify talked about the book, the author had a quote that said that he didn't intend these code samples to be used in production, but obviously we all know that happens. I mean, why would an author make a statement that they wouldn't expect their code examples to be used in the real world? What would they expect? They're teaching people how to write code. If the code wasn't intended for real use, then what are you trying to teach? So these quotes were taken from the article. There's the URL down at the bottom of the review. It's also in our slides. So I'm going to add the bad code example that was taken directly from the book, and I'll talk briefly about that. So those of you that I can hear snickering may have already noticed that they're just blitting user input right out to the output stream. So this is on page 60, and it's code listing 38 for those that would like to take a look at this. So real quick you can see they're pulling a bunch of parameters directly out of the requesting, and they're just writing the response right back out. So that's classic and very, very simple cross-site scripting. So that's my bad code example. Now I'm going to add an exploit to this example if you can call it an exploit, just because I already have it and I'm going to paste it. So really that's fairly proof of concept cross-site scripting, but it works great. So now one of the most important things we're going to add an example of how this code can be fixed. It depends on your perspective. So our fix for this was to use the OWASP's Enterprise Security API. It's pretty cool. You have to know what context you're in. In this particular example we're in the HTML context. Most of the bugs that we found in this book, which we found in Umber, were in the HTML context. Although we did find one that was in the JSON that was sent back and forth, so it was in a JavaScript context. So we submit this fixed code example. Then what we'll do is we'll go over here to the review. You can tell by the little unlock symbol here that this book doesn't fare very well. I'm sorry. For this one, the code example that they gave, there's no storage at all. It just basically blits it right back out. So we simply are encoding it when we get it. If you're going to use this in a backend database, which none of the examples really had in the book that we looked at, you'd obviously want to be doing validation for various other things. SQL injection. We don't have the functionality right now, but there'll also be the ability to comment. So for example, if you wanted to raise that issue or say, hey, guess what? You didn't consider SQL injection. I would recommend doing it this way. That's one of the features that we definitely are going to be adding. I don't have one. We actually just started reading about it and there was a video that was released. So we decided it was not a bad thing to add in for this example. So for the full review that we have, you can see there's the fixed code example. We have the exploit. The ordering is reversed for some reason. We have the summary and then we have the bad code example, the fixed code and the exploit. That's pretty much it. It wasn't intended to come out in reverse order, but all demos break. Yeah, include, yeah. Okay, so to summarize, really the key to fixing our non-human security problems are to fix our code problems. To fix the code problems, we really need to teach programmers how to write good code. And the key to teaching programmers how to write good code is to use textbooks that teach good software development practices. And the majority of the books out there today from everything we hear from the university environment is that the books really teach bad programming practices from day one. They make it so simple that they teach people how to write bad code. And we really need your help, you know, to make this happen. Now, we do have one final request. You know, the site is in beta. So if you find problems, you know, please don't pwn us. You know, contact us. You know, tell us, hey, you know, you have a bug in your site. You know, you can have X vulnerabilities. You know, let us know the contact information on the last slide. Let's see, we've got about four minutes. Any real quick questions? Okay, back there. Louder, please. Okay, the question is, he's a student at university. What should he be doing to try to fix this on his side? Definitely submit the books that you are using in your courses to the site so we can get them reviewed so that you can point them out to your professors. Hey, you know, this book stinks. You know, it's got all these vulnerabilities in it. Why are you teaching us to write bad code? I mean, this is going to be a grassroots from the bottom-up effort and we really need everyone's help. Any other quick questions? Yes, louder, please. What do you do to get your university actively involved? It's from the students up. I mean, you as a student, you know, can take this site to your professors and say, hey, you know, here are the reviews of the books. If you're choosing a new textbook, you know, please submit the book in advance to get it reviewed. And if it's not any good, you know, give us a decent textbook that we can learn to do things right. Yes, put up sign, spread the word. Anything that you, you know, care to do, please. And once reviews are up, link to them. You know, put them on your Facebook or MySpace or whatever sites that, you know, my school is using this book. This book stinks. You don't believe me. Here's a review of it. The more links we get to it, the more visibility we'll have. Yes. Well, that's why we have Hack the Textbook. It's just that, you know, when you, when we're sitting here doing development and we needed an official, you know, name that the publishers, you know, would not, you know, choke on, you know, for the publishers, we'll tell them it's tdbsp.org. For the rest of the world, you know, Hack the Textbook is fine. But again, you know, we want to, you know, kind of a professional presentation to this. Okay. I believe that's, yes, was one more question quick? No, we're not. Not this time. This is really, this has been a project that I have had some discussion with several universities that I've worked with on and off for a couple of years. And back I think about February, I'm not, you know, really a web developer. And I hit my, my cop says, hey, you want to do a project? He said, tell me about it. And he said, yeah, cool. So, we kind of started on it in late March. And it's been spare time. But we hope to find a lot more time now to, you know, try to get it up and going. We hope to have the full site up and going probably by the end of the month. Okay. Any other questions? I'll be glad to take them out in the hall. Contact information, website information. And DEF CON will have the slides. So look for them on the DEF CON website sometime in the next couple of weeks whenever they get around putting them up. Thank you.