 Okay. Our next talk is on Java. Actually on a specific form of attack on Java. Script. For the evil side of Java. For the script kiddies. This is Injun. He is originally from Siegen, which is part of Chaos West. I think he now lives in Bremen, if I'm correct. Please, let's have a big hand for Injun. Come on. All right. It must be filled up to the last place, because I can't see a thing. Just to make it easier for some of us. Is there anybody who is not a native German speaker here, then shout, no! Then I switch to German, because it's a little bit easier for me and probably easier for you. You're okay with that? Okay. No, let's switch to the language. Okay. The presentation today is, so to speak, a thing I did in a very short time. I wanted to give an introduction to cross-site scripting. And because I wanted to make it more funny, of course, I changed everything. I completely changed my normal file format and tried to make it as a demo. And what do you have to do? You have to bring the whole thing to the browser in this Java scripting thing. That means that what you can see in the background is actually my Firefox. And you can attack exactly the way I'm going to demonstrate right now. While I developed the demo, I actually used cross-site scripted myself once or twice. So the thing seems to be really dangerous. The meaning of the presentation is actually to give you a very basic introduction. And if someone has never seen it, then maybe it has this build effect. That would be totally cool. If not, then not. And in the end I'll give you two or three more photos. If you really want to build a web application, so a website or something like that, with a database on the back or something like that, then there are one or two words that you should have in the background while you're programming. At the university I actually had a photo. They had these two words as often on this photo as it was. So that you can somehow notice it. The people are not present today who could have read it. But I think they still have the two words in their heads. Good. We don't have time for questions or questions. We'll do that in the lounge. I'll just stand there a little bit. You can just come by. Otherwise, if you don't understand anything at all, just go in. That's the professional stage where I was the sound engineer. The sound engineer was the sound engineer. Good. Why do I do that? That's what I just explained in principle. I had to keep an eye on it. It should be an introduction somehow. And then I just engineered my slides over. And I really wanted to do something with 3D. And I thought, I know. For cross-site scripting I need the third dimension so really deep. If someone gets bad, just close your eyes. I keep talking. Otherwise, cross-site scripting is incredibly easy to avoid. A weak spot, like all the others. And still in the 2017 list of the Open Web Application Security. Now I forgot how to say it. Projects, exactly. On place 3. Still relatively often. And the string that we have right away. You can just throw it into every search field. Maybe something comes out. You can just play around. That works then. Good. Can we start? Yes. Good. Thank you for this incredible feedback. Good. The first thing I have to explain briefly so that we are all on the same page. What is this weird WWW? I will use the term server right away. So we have to find out briefly what a server is. I wrote that down there. The web server is what provides us with the website. You have to imagine that a little bit like in a restaurant. I'm sitting here in my restaurant. I want to have something. It comes from the kitchen. That means my server is like the kitchen. Then I order it via a protocol. That is usually in the WWW. So the defined protocol is called HTTP. That is in this case the cell phone. I give my order to it. That is called a request. It goes to the kitchen. It says the kitchen. The kitchen. So my web server mixes it up. And then it lets you transport it from the cell phone. If we have something like TLS, which is very secure and switched on, then there is a certain chance that the device will not change without the cell phone being connected. If not, then everything can happen in between. But that is not the topic. My food usually comes in the web in this form. It is called Hypertext Markup Language. That is the document format. Everything is written in it. That is something like the plate or the table here. And that is delivered to me. And I have to process it by eating. That means I take it in me. So I am in this picture of the browser. And I then swallow everything that comes there. And Javascript is on top of this HTML mountain. That is something that dictates my behavior as a browser. So I can then, in principle, the server, if he puts a Javascript on his website, brings something else to do. For example, stupid to tell, to stand up, to go to the right or left. You notice that under circumstances maybe something critical is already being connected to Javascript. Because of course that sets out that the whole delivery chain from kitchen to here believes that the medanix will build in what breaks my browser. Or that brings strange things to be fabricated. Well, now there are a few insurances in the whole browser that only allow certain things. But there were also weak points. You can try to be careful in general. It would be unpleasant if I didn't deliver the stuff that comes from the kitchen, but that comes from someone else. He put something in there or something like that. And I definitely don't want that. And the kitchen and the whole delivery chain could actually do something against it. And today it's a bit about how an attacker can put something in the kitchen in the pot and then deliver it to me. Or rather the real example that I bring today is that it breaks something in the pot. So, I'm the little one, the web browser and the kitchen in the back. The cook is the server. That's how we put the basic items. And then we can take a closer look at what I actually want to tell you today. Cross-site scripting attack. You can simply take that word literally. Cross-site means it goes beyond the band. In principle, attack communication with the victim communication is crossing itself. The principle, there are several types of attackers. There were types like cross-site scripting attack. Reflective, stored, what we have as a demo today. CSRF, so cross-site request forgery would also be a special version. It works, but in large and all always in the same way. That the attacker sends something to the server or sends it to someone. The server then processes it in the kitchen in a way that doesn't prevent any strange things in my food. And then it delivers it to me. Because I want to see the website at the end of the day. So far, of course. Wonderful, I can now click and click. That's great. Well, how does something like that actually work? And we'll go through this web call and do a cross-site scripting attack. Because the reason why I did that in this Impressed.js is that it is practically already stored with JavaScript. And then you can do cross-site scripting yourself. And that looks better. And you can tell me if it actually was not that bad at all. Good. So we have a common thing. This is a sign-in-web-formula. Usually it can be something like a posting in a forum or something like that. The only requirement I have is to send something to the server. I have tried to do it easily. And probably you could not read the script there. But in principle, there is not my username but there is this HTML control sign for I bet there is a program now. Then there is a very harmless program that should just pop up a message and then it will be closed. That means I just enter a sign that came to my mind that could have an interesting result. That's definitely not my username. You can already see what you can do against it. You can check if someone really is scripting and alerting. That's just a relatively unusual name. Maybe nobody wants to say that. Well, I gave it to you. The password is in this demo, it doesn't matter. That's why I just throw it in. That's a very common formula. You saw that in HTML. You got it delivered like that. That's something like, I don't know, something like that. I now have a variable name password in the input field with a value, which is down here. And up here in the username I have basically this strange thing there as data. And these data are now moving from the attacker browser. That could also be yourself. They will send it to such a HTTP request. So my order, or the order now in this case from the attacker. And there they just land as variables somehow in there and are sent directly to the server. So magic is never really there. That means that this is the specific message that the server is easily delivered by my attacker. What does the server do with it? The server processes the stuff in such a program here. That's actually a bit of Java or something like that. It's a bit of an example of what you can do with it. So a relatively common framework with which you process data. How that actually happens is actually pretty much the same. It's important to note that there are some parameters that you normally save briefly in the main storage. So you notice how the hot packs go into some variables. And then comes the important step. You want to save it somewhere. That's what I do here with my self-sufficient function sign-in user. There's exactly the same username that my attacker just entered. My absolutely creative password. And then it's just passed directly into the database. Let's see if that works too. Ah, that doesn't work so directly. I wouldn't even show it. But the password is shown. You can see that this script isn't shown. Because it's a script. At this point, it's not directly displayed. That's the place where I myself have cross-site scripted. I'm going to open the cross-site scripting right away. That's what the thing is now saved. In principle, as an attacker, I've put something in the kitchen storage. Just a small, poisoned can or something like that. That's pretty dangerous. Now comes the moment where I want to have something. The kitchen goes back to its storage and gets the ingredients out. And I get a website that can show me as a user. With such a username, for example, it could be something like the administrator who urgently wants to have the list of all the users. That would be nice if he could show himself as a user. And I could manipulate his browser in some way. That means it looks the same as before. He builds it in a website. Here you can see this markup of a website. He's making a list with this output, a list of users. And of course, if he asks that out of the database, with the username in this case, it's completely free. He adds the string to the place that I assigned as a user name as an attacker. And of course, also a password. That means he builds a website together and packs a cramp. Now you could have a certain idea of what you could do right at this point. But I don't want to do it myself. Well, that means he makes a list and that's how this website looks like. He builds my server, or you could look like this, he builds my server, there are all the users inside. And one of these users has a strange name. In this case, the hypothetical administrator who wants to look at the user list right now. And he gets something like that shown. It worked wonderfully. I was a bit scared. What's happening now? In principle, you can see nothing is shown here. And I was a bit scared, it was very explicit. But my browser just took what was here as a script. Because he sees this whole markup and the one markup said here's a program for it, please immediately. And luckily there was nothing in the script like explosions, starting the Third World War or something like that. But there was a message on the cross-site script that says this is harmless, but I didn't want to destroy my computer myself. I do that often enough. In this case, we can just click away. Everything is fine. But in principle we now have a script in the browser. That might be dangerous for the first time. We'll come back to that. Don't look at it yourself. Well, what did we do? We had an attacker who had a strange user name or whatever it was for an input or how you really enter something he might go directly to the database who was in the situation unfiltered to throw data into the database from the server. The server just unfiltered and unfiltered this thing out of the box and then gave it to the victim again myself in this case. And the victim then started to behave strangely, to pop news or to call websites or whatever. In the end you can actually do everything that the user could finally build in javascript, send data, send data and so on. But if there is a certain sandboxing procedure like your own browser tries to protect you in big and big, that's not good for now. The question is, what can we do against it? And the incredibly depressing answer is, actually, that's not at all difficult. The problem we had at that point is actually that we didn't adapt or that there are some unknown content that we just threw into such a HTML context. It was in front of the database context and before that it was somewhere in the attacker context and we just took it and just unfiltered it into it without thinking about it. Certain things that could be stored in my database have a special interpretation in HTML. Namely, especially these tiny things. And that tells me that it's incredibly easy. If I have something in my database like a tiny clamor, then I actually want it to be a tiny clamor in my browser and it doesn't start interpreting it as a special sign. In the end, I simply have to convert all special signs that are there, so special signs in the target context, in the case of HTML, into something that corresponds to a normal sign. There is actually just a database that you just have to use. Maybe you noticed that at this point I didn't just take out the username I just said, code that again for HTML and then we're done. And that makes such weak points so incredibly depressing because that should actually belong to programming such as, I don't know, drinking, living or something like that breathing and similar things. Good. If you want to have help, I'll give you a quick review. There is an open source project, an open web application security project and they provide you such a code for everything you want to have, for example. They also provide you with these top 10 and then you can read again what you could do again, something like input validation. I don't even have to put this stupid name in my database at all. Who is already called script? Are you still with me? Have you ever slept in? Yes, they don't call again. Good. So, so to speak, the pre-setting. The stuff is not directly dangerous, but what can go wrong? We have a lot of data. We have a context in which we don't know what happens. It's easy to avoid. In the end there are a lot of mistakes that have any side effects. For example, no one would come up with any important industrial systems with such a strange web interface like cross-site scripting. Since the first windpark operator does it, there were some people in 2017 who analyzed these web interfaces and also found cross-site scripting approaches and then actually controlled wind power. It was a bit large-scale, because of course we write software once and roll it out everywhere, then you have the weak spot everywhere and then you can switch out or wait for this energy lecture yesterday. I also come from energy informatics, then you know that this is not good. So, there are a lot of things that the attacker can do and it's much nicer and much easier. It's just incredibly easy to lift up, so it would be nice if at least the top 10 of the O goes through, then you know what you shouldn't do. Now I'm too far. Okay, so output encoding and if not this last picture completely convinced you that you need 3D, where you can recycle your graphics, then don't try any strange 3D-photos, because it does a hell of a job. But it's nice. Thank you very much.