JAVA Swift and Secure: Racing Towards Resilient Cybersecurity in Java Applications / Калоян Георгиев

This talk, presented by Kaliyan Georgiev, focuses on the balance between speed and security in Java applications. He explains the importance of integrating security practices from the onset of development, using examples like the 2017 Equifax breach to highlight the impact of vulnerabilities. The speaker covers best practices for secure coding in Java, such as using secure random numbers and proper password management. He discusses various security frameworks like JBoss's Elytron and Spring Security while emphasizing the significance of logging and telemetry for monitoring application behavior. Throughout the session, he shares implementation techniques, including reactive programming with Spring Flux and performance enhancements using tools like GraalVM. The demo illustrates how to structure applications to be both fast and secure, with practical insights on avoiding common pitfalls in security design.

Hello everyone. Oh, my name is Kaliyan Georgiev. I am a principle engineer at Bay Saave. And an interesting fact for me is that I'm in my 13th year as a software engineer at the company. And the other interesting fact is that I have twins, a boy and a girl, but that's enough for me. And lastly, let me just tell you, in the photo I'm riding an Opel

Corsa. which is neither fast nor secure. But that's why today I'm going to present to you how we can make a fast and secure product, I've prepared for you in all the slides in a row, and as you can see in the table of contents, an introduction to the basics of security in Java. Oh, I'll tell you about high-performance and fast Java applications. I have also prepared

a short or not so short demo about how I think such an application should be best implemented, and then we will talk a little about the demo. I'll tell you in detail, actually, the whole structure, how it can be improved, of course, because, without making excuses, I didn't have much time to make the great demo that I wanted to, and of course, the conclusion of all this

is, I think you saw on the first slide the QR code that you can scan. for the Q&A session. Well, in the introduction, this is probably an unsuccessful attempt to illustrate a fast car without brakes, and how Swift is actually a non-secure car. And so, in general, what I want to do as an introduction to you on the topic is that it is always best to have

a balance, for things to be both fast enough and secure enough for, and in general, for what we want to achieve as an end result. And now I had prepared a joke to ask the audience which is more important, being faster or being safe, but they are unlikely to be that receptive. Rather, I'll tell you that, as I assume most of you know, in the product world,

all product people want to have more of everything. And I personally remember my thesis reviewer. I just decided to get two bottles. One American and the other Russian and I brought them to him, like asking him which one he wanted, and he told me he wanted French too. So, in general, it's the same with applications in the IT world and in product applications. really, besides being fast,

we also want UA and UX to be up to par. Ah, but this has its price, of course, and I hope in the case I can actually show you how we can not deprive ourselves of all these things and still have a very good product. The other thing I wanted to mention to you in the introduction, and it again touches on the security topic, is the 2017

incident with Eco ifax. And I guess some of you were interested and know very well about it. And there, about 150 million PI data of Americans was leaked. The biggest problem was actually that about 200,000, if I'm not mistaken, were PCI or rather credit card data, for people who are not in the payment industry. it was a fairly minor vulnerability, I would say, that they simply hadn't

patched for more than four months . And what I wanted to tell you about this topic is rather that even a small vulnerability can bring down the entire product, as in this case, right, there are not only financial losses, but also reputational losses for the company. So security is very important to happen on time and not to be underestimated. And since this other thing I wanted to

mention to you is about Life Walk a lot further back as a Security Bridge, but then their CEO Toth Davis decided to show that despite the breach in their system and the stolen SSN data and so on , in fact, this is absolutely no problem. Like he had put his SSN and his full name on many billboards and buses. After all, he was sure that nothing would

happen if people knew his name and surname. And yes, he is the CO of one of the largest PI data companies in the States, but it actually turned out that he has more than 13 confirmed loans and over 80 attempts to make this happen. So never underestimate the ability of others and security. Now in this slide, besides wanting to brag that I was recently in Croatia, that's

why I put a castle, and actually it's the basis of the security illustration, as I see it. And actually the outer layer is the faallla, and the wall is the authentication. The guard that lurks above is actually authorization and the limits. And now it's the difficult hall with the flag. And in fact, this is the encrypted data. So what I've prepared as bullet points is actually what

are the best practices in Java. and I've given, I've just drawn a small example of how we can actually use a randum that is fast, but on the other hand, it's not secure and predictable. And actually, good practice is to use secure random, which is a little slower, but fast enough for 90% of the needs we would have to use it my opinion is a good combination

between Swift and Secure. Oh, I forgot to mention, before I even came up with the title of the presentation, a lot of people asked me if I was going to talk about Swift. No, I'm not going to talk about Swift as a programming language, I'm just going to talk about Java. Swift in my mind is aa speed. going back to the topic of bullet points, in addition

to secure random, I have prepared best practices for how to use a password in our applications, and quite often I'm sure many of you have encountered a string for getting a password in the object at all, but also In fact, a string is very dangerous to use, since the only way you can really clear the password when it is stored in a string by the JVM is

through the garbage collector. Now many of you will probably say you can call the garbage collector with system. GC and he should come and actually clean up what was in the string Password. And I would rather explain it like this for people who don't know, and system.g GC works like the way you would call a waiter, right? You raised your hand, and the waiter saw you, but

he will come when he is free or when he remembers. And it's the same way with System GC. So in order to quickly and easily free up and clear memory, it is much better to use a password charm array. I have also removed the Java X cryptography key. These are good practices that can actually help us without using external libraries, but are directly built into Java, and

without using, as I already mentioned, an external library, because the risks of using an external library are very high. Ah, I remember one of the security bridges that my colleague Marto and I discussed. There was a color library in Anguilla. And a white hat hacker had simply decided to dump credit cards through this library. I think over 400 projects had integrated it because they decided to use

something ready-made. So here my reference is rather to use things as close to the programming language as possible without external libraries, without transitivity and so on. And in the third point, I have actually taken out all the Java Security Frameworks that I have encountered over the years . They made a good impression on me, and are rather innovative and can actually be used in the Java world

for JVM, for containers. And first of all, I actually removed Jossa's Security Subsystem, which changed from JBoss 7, that is, after JBoss 7 from JBoss 8, and in fact its name is now El elytron. And an interesting fact about it is that Jos security and can be configured and used to a large extent as a keystore, as an authentication database, right? There are so many great possibilities.

Oh, but for the next point, Spring Security, I had prepared a joke again, which you can see, that this is actually the favorite library of all people involved in spring and security, but the biggest problem is when you have to configure it. And I wanted to say that this joke applies to Spring Security, Electron, Jaka Security, and Java Enterprise approaches. It is very important to spend time

on each such security framework, to be natural, to be certainly configured in the way we want to use it in our application. and at the same time, this thing should help us for better security in the framework in the application that we use through the Java framework. in the next slide, what I have prepared is actually something that I hope Dido Tsvetanov has come to honor me

today and watch. And something I learned from him. And actually, I've heard it called functional programming in Java, and in many different ways, but it's about web Spring Flux applications where we actually get both security and speed and at the same time asynchrony of requests. It's no coincidence that in the image that my chatbot generates, you can see the blocking and non-blocking And as for blocking requests,

I guess all of you know that we actually have one request per thread and in some cases, not even in some, in many cases this is great, but it's very important to know that it actually works like waiting at the counter at the post office , right? If the person in front of you fills out the form slowly, your turn will come much later, and vice versa,

right? If they're faster, you'll be able to get to the counter faster. And while through mono and react programming we actually have non-blocking requests, which you will literally see in the demo, they can fly in my eyes, even on my machine, which is not that powerful. Please forgive me, I'm just going to drink a little water on the last point about Java Performance, I've prepared three that

I've only tested, but they have some prerequisites, like specifically for Virtual Thread you need Java 21 and up, and they actually replace the pool and what's very positive about them is that they actually reduce the lancн tool. real virtual trades, even though the term Virtual is used, they are not virtual like cryptocurrencies, right? I'm a fan of cryptocurrencies too, do n't get me wrong. But quite often

they work in a very perfect way. As for Gooby VM, I admit, I really wanted to prepare the demo with Grau VM, but again I'll make the excuse that I didn't have the time I wanted to have, so to speak. But what I have prepared for GraVM and really want to share with you is that very often in programming environments I have heard colleagues tell me that

Java is slow, that the JVM is slow until you start it, and so on and so forth. Well actually with GRVM things really really fly. And for the next lecture at def.bg, I promise I will prepare the demo with Grvm and we will test it in parallel with sprint and security part. The last thing I want to tell you is that everything we mentioned is about Open

telemetry, right, and it 's very nice to have security, it's very nice for your application to work quickly , but without proper telemetry and logging, you're basically blind. And even if they try to hack you, there's no way you'd know that this is going to And now I'll show you how a fast algorithm works under load, taking just one second the screen. Yes, I hope you see

now. Ah, I've prepared a project each of you will be able to download after the presentation. I'll upload it to GitHub, there will be a link to it in the presentation itself. Now I'll quickly take you through and tell you what I actually did. As you can see, it's not just something big . And four or five classes of JavaScript that I use for tests, and all

of this happens with Mavon and a POM XML in which I have configured Dependency. And I use Bucket for J for Cash. And something I've prepared in the next slide after the demo, to tell you why, what are the risks of using cache, how fast it is, and so on. And what you see as a class is a rate limiter, which actually implements the springflake web filter.

Oh, I've actually prepared a max request per seconds configuration, which if I had time, I could of course put in some property tool, but even with the hardcode, I don't think it will be good for the purposes of the demo. And as you can see, I have prepared a filter through a web filter chain based on which we can override this constant that I mentioned for Max

request per seconds. Actually, and our server starts returning Tomi Request 429 as an error. I've prepared a quick JWT, and in it I did something that I wouldn't advise anyone to do, right? For the purposes of our demo, I just did it. And the expiration time of my JWT is one hour, as you can see. And Secret Kia is again hardcoded in Java. This is certainly something

that should be replaced with a Property in Volt or some other Key Secret Store, but where can we extract it from? And I just forgot to say why expiration time is a breakthrough in the system for me. In reality, when we have such a large app, we actually leave our system open for a very long time for people who may not be authenticated, right, and get hold

of a given user's JWT. So, in general, we need to be very careful with the time management of the accuracy tokens we issue and ensure that they are valid for the exact time we need them for. Oh, and the last thing I wanted to show you is the three points I've prepared. One is for generating the token. And the other one is, we actually check the secure

date and whether the user actually has a valid JWT token, because you'll see, we'll try to break it with such an invalid one and a public one, which and actually this is one of the problems that I mentioned when I was showing you the castles aa from Croatia. Ah, but in reality, security is always layers and the vulnerability in our application can very often be just such

a public endpoint, and since it has no verification, if the user manages to break through the file, in reality, in this case too, we don't have reading from the database, but it can lead to SQL injections, database overload, server crashing, and so on. From this perspective, what I wanted to mention to you is that it is very important that public inputs are always very well defined and

have their own rate limit filter, which as I told you, we have actually limited it at the moment to a maximum of 10 requests per second, so let's move on to the crashing of applications. If there's a QA in the room, I'm sure they'll be very happy. Well, many years ago I was Q. I loved breaking things. Apparently my kids are QA too, because they still love

to break things. a W script on K6, which in itself, as you can see, is again something very short, which can certainly be extended. And there are actually virtual users per second that we will load the system with. And actually the duration of the attack, but I made all these things so that they can be controlled from the console. And the only thing we need to do

is generate a new Oh yes , this is our public endpoint, as you can see. This is a public endpoint permission without token. And we generate the token, we can put it in JWTio. And let's see, it's actually expiration, user. As you can see, it's a very simple structure, something I talked about in December in the Java user group again, specifically about JWT tokens and Pass Keys.

It is very important not to keep sensitive data in the JWT and again to try to minimize it to only the purposes for which we need it. And our token, as you can see, expires at 2:30 in an hour. Oh, wait a second. That's right. We put it on. I've prepared 1200 here. Do you think the system will hold up ? That's right. What I did right

now , I ran our script with 12 requests per second, 12 virtual users. And for 10 seconds, the attack is on, or rather, to see if our application will behave as it should. But what you abstract away from that 75%. This is purely because of the script. As you can see, here are four checks and based on that, it actually gives them that they failed. Only 25%

have passed. That is, we managed to make 120 requests as aa in 10 seconds as the max request per second, as you saw in my configuration is 10. And actually, I let the script run with 12 requests per second, which you can see here is 83%, that is, 100 of the requests managed to get a status of 200, and the others were exactly at our raid limit

and are 16% 20 requests actually failed to pass. Now, I had prepared a small, at least from my point of view, ray-limit. What do you think, will my humble machine be able to handle 100 requests per second ? We'll see it now. We are actually currently processing. second, I didn't pick it up. In reality, we are currently processing 100 with this application, which I mentioned to you

that in the next two slides I will explain in detail how things happen in the application. And you can see, we managed to make 1000 requests in 10 seconds. Oh, absolutely all of them returned 200. Okay, so our server manages to process 100 quests per second. What do you think, will we be able to process 1000? Although, as I told you, I am with a modest unit.

I forgot to mention that if you want to do such a test with the application I have, you just need to install the graph on your K6. And as you saw, we managed to process 1000 virtual users per second and even if we try to attack our server with 1500 virtual users per second, it will not start returning an internal server error 500, and it will manage

to process, as you can see, absolutely even more than 10,000 in this case requests, which will return 200 and a little less than 5000, which actually blocked this attack. That's right. And I think I've made excuses a few times that I didn't have time, but as you can see, the biggest minus right now in my demo is that I'm actually, if I only look at the server

site, I'm blind. I do n't know what's happening right now. I don't know if anyone is bombarding me, I don't know if it's even happened that I'm taking on traffic of 1,000 virtual users per second. So that was my point about Open Telem. It is very important to always have good logging, good security, and if possible, a fast application. And that was with my demo. Just a

second. Yes, I already mentioned it to you, but speed without safety is a disaster. something that is actually the main point of my presentation and in reality, UX can also suffer from the fact that we decided to make our application quickly. As for the demo, what I have prepared is actually, first of all, speed does not mean that we will not have security in our application. And

the other thing, which is super important to me, is to always have a security filter chain, as in the case of our application. And actually, when we decide, we run this filter, when we decide, we stop it for testing purposes and for test environments, this thing can be stopped. And actually what we saw in the demo is that we were able to do react authentication, which as

you saw can actually process over 1000 users who authenticate or hit our end point, which requires JWT or authentication, and the most important thing is actually that we had no problems with the input output stream and that the validation of the token happens super fast with a cache that is in memory, a cache that as you can see I left a bullet point in this case, that

actually just because we cache something doesn't mean it's insecure. On the contrary. And Bucket For, which in this case we used for this demo, actually convinces us otherwise, and we can use the cache, it should be fast, in memory, and it should work. Yes, I agree that in this case I ran it on one core, but in reality it works on one note. If we want to

have a similar application on more than one Note, we actually have to use a shared cache, but again Bucket For Jt is such a solution, so maybe in some of the subsequent lectures I will introduce you to this, but the last thing that I did not demonstrate to you is that it is actually very and it is very important to have testing, as I demonstrated to you,

because makes us feel safe, not to panic, to know that our application can withstand this stress and we can test it long before the production phase. What I've prepared again for the demo I showed you, a small table of what we've actually managed to achieve in terms of speed, security, and resolution. In this case, we do not block the flow, we do not do expensive input, output,

and we achieve this with monoobt and JWT without a base. To have more speed in the application, we don't necessarily have to use a session. I know that very often product people want us to have a session so they can track user behavior, but it can be added in the frontend or elsewhere, but not in the authentication apps we use. And in this way, as you can

see, we again gain speed, security, that there is no face measurement through the states, and in fact we have state tokens. And the third thing I learned is that we managed to put a lot of strain on our I admit, I haven't tested it on 100,000 requests, but I assume that it will be able to withstand about 10,000 even on my humble machine . And actually, the

security in this thing is that by having a raylimit, we actually limit bot attacks by IP and when you have speed, even if we add an external library, it won't really slow down the response time much and in this way, we will actually gain by having good monitoring of the application and not missing any hidden behavior in the backend. Well, the last slide that I've prepared is

actually something that I think we should take away from this lecture. In fact, security should be on by default. And it shouldn't be something we do as a feature, it shouldn't be something we think about afterwards. And from my point of view and I guess from many of you, we actually need to with security at the very beginning, the very beginning of the product, to talk about

it with the UI and UX people, to tell them what we actually need to do to have fast accuracy, to meet absolutely all the expectations given by stakeholders like regulations and so on, to have 2-factor authentication, biometrics and so on. and absolutely always this thing should be performance tested to know what the limit of our container is, of the application we use, we are lifting, so that

we can always leave some buffer, if we have managed, let's say, as in our case, to make over 1500 requests per second. It would be nice to limit it not to 1500 to be on the edge, but at least 200 requests lower. And since I was recently at a Cyber ​​Security conference in Bulgaria, there were police commissioners there, people from the services dealing with in the IT

world, but also from state institutions. Two things there. These are my last two bullet points. Two things impressed me . Most of them talked about vulnerabilities in smartphones, and each of us has one. It is clear that this is actually the new authentication mechanism. We use it for absolutely everything, but we need to know that in fact, right now, that's where we are most vulnerable. just a

piece of advice from me: absolutely all the measures that can be taken to secure your phone, including biometrics, face recognition, and so on, because I saw a lot of cases at that conference that I mentioned, where people are actually hacked through their phones, and also because they haven't protected them. The other thing that really impressed me at this conference was that everyone was talking about passwords. Not

only that, but a large 90% of the cases were passwords or pins. And something that I realized about two years ago, something that we implemented at Paysfe in our company, and these are the so- called Passkeys. Um, I don't know how many of you are familiar with them, but really, for me, especially after this conference, this is a place to go from the perspective that they are

actually impenetrable in the way they are made and of course it is very important how they will be used in the given application, but they really ca n't be guessed, just like passwords can't be cracked, and they are also in most cases kept in a certain place on the device from which you created it. Whether it's a phone, a tablet, a laptop. So, this is exactly what

I was talking about in December. I actually told you how we implemented it, how we tested it. Oh, we did absolutely everything necessary for this thing, like security testing, testing and so on and continuous integration testing, which is going on and right now, most likely, if I open the Slack, I will be able to show you the latest results of the absinthe testing. So this is something

that I think is the future, moving towards security without passwords, without them being able to be broken by hackers, whether they will be packets or something else. I think this is the direction. the last thing I want to tell you is that actually regarding the presentation, if we want to be fast, we have to be calm, we have to have thought through absolutely all the scenarios, and

in order to be calm, we have to be sure. Do we have any questions? We have several. Yes. And so. So we might start with those. Anyone who hasn't asked themselves the questions yet can scan Vivox and ask Kaloyan. Here we start with this one. And the first question is why Reactive Programming instead of Virtual Threads, is n't it already a risk to use an external library

like Reactive? And in this case it's integrated, but I think I mentioned that to aa a little earlier in the presentation. I also mentioned Virtual Threads. So for the next presentation, it will be prepared with Virtual Threads and Grow VM, and to go into detail, we can also compare them with React programming. Is it better to use Verk instead of Webfx from a performance perspective? And I'm

not familiar with Verk, I admit. Oh, I would look at it, of course, to compare it to the webx and certainly something that provokes interest in me. Thanks for the question. What should be included in every secure Java application? first of all, there are limits, something I forgot to tell you. Actually, a raylimit can be done both at the firewall and at a lower level, but for

me the source of truth should always be in the Java application, because this way, even if we change the JVM, the framework on which we run it, and so on, it will actually remain and we will actually be able to Well, I think I answered all of them.