Final Touches and Security Considerations

Though our application doesn't allow a user to update a task, 0:00 other than marking it as complete. 0:03 We do allow users to add new tasks. 0:05 If we look at the controller method that handles this requests for adding. 0:08 And that's in task controller, we have add task right here. 0:12 We see that it calls upon the task services save method. 0:16 Let's look at the implementing class for that service. 0:22 So the task service impo. 0:25 We see that this class a save method calls upon the DAOs save method. 0:29 So let's open that class. 0:34 Now this one is simply an interface here that is one of those 0:37 spring data JPA repositories that's generated when we boot our application. 0:42 Specifically the save method is inherited from the crud repository and 0:49 is nice for creating new tasks with all fields populated and even updating tasks. 0:54 If we expose to users a way to do that. 0:59 The problem is that in order for this to be effective, 1:01 we need to have the user field populated in the task entity before saving or 1:04 it won't be associated with the user. 1:09 Let me show you two ways of saving our task. 1:11 Let's start by grabbing the current user in the controller. 1:14 So back in the controller, we'll grab the current user. 1:17 To do that in this add task method we'll add a principal parameter whose 1:21 value will be populated with the username password authentication token object. 1:25 Which is implemented the principal interface. 1:30 So principal. 1:32 Now, we could get the user entity in one of two ways. 1:37 The first way is by fetching the user name from the principal, 1:41 then using the user service to grab the user entity by its user name. 1:43 Here's how that looks. 1:47 Let's declare a user variable that's one 1:50 of ours not any number of these other ones. 1:53 I'll call it user, and I will use the userService 1:57 "FindByUsername" and 2:00 then Principle.GetName. 2:07 If you recall from a previous video, the principal object 2:11 will have a method named getName whose return value will be the username. 2:15 Now I do see that userService isn't recognized that's because I have not 2:20 auto wired it into this class. 2:24 Let's be sure to do that. 2:27 Auto wired. 2:28 private UserService userService. 2:29 There we go now down here it's recognized. 2:33 Now before we use the task service to save that task we better associate that task 2:38 with the currently up then a gated user which is now stored in this user object. 2:43 So to do that I'll do task.set User and user. 2:48 And now when the test service saves the task, 2:55 that user will have been associated with the task. 2:58 So everything will be associated just as it should be. 3:01 What we should know is that calling upon the userService, specifically its fine by 3:05 userName method will result in an additional hit to the database and 3:10 note this is not an expensive query to the database it will happen very quickly. 3:14 It's still another query to the database. 3:18 If we'd rather not hit the database again we can use our knowledge of java and 3:21 even run some quick test with output to see 3:25 that the principal parameter-- this principle parameter right here-- 3:28 is populated with a username password authentication token object which 3:34 has a get principal method whose return value is going to be the object that is 3:38 implemented the user details interface in the typical spring security setup. 3:43 So it turns out that we don't need to hit the DB for 3:48 our user entity we already have it. 3:52 So how do we get it like this. 3:54 Let me show you I'm gonna delete what I did here And 3:57 will first start by casting the principle to a Username Password Authentication 4:03 token object, there's that cast to the principle. 4:10 Then we call the objects, get principal method, so all surround this whole value. 4:16 With parentheses and call getPrincipal. 4:24 And finally we cast that. 4:29 to our user object which has implemented the user details interface. 4:32 User, just like that. 4:39 And there it is. 4:43 So this is another approach and it definitely works. 4:43 Let's run the app to see if it does work. 4:46 I'm gonna open my run panel, and run that boot run task. 4:49 And the spring application is booting. 4:57 And has now started successfully let's go back here and will need to log in again. 5:01 I'll login as the first user that is just user 5:05 cool now we've discussed users and roles let's try to add a new task. 5:10 Discuss security Great it looks like it added well. 5:15 Let me log out from the user account and login to user 5:20 two to make sure this test doesn't also show up under user two's account cool. 5:24 It certainly does not so if I log out and log back in as the first user. 5:30 There it is still there for us. 5:35 As I said this is one approach though it's not the only one. 5:39 If you'd like to pluck the stuff out of the controller and push it all the way 5:41 down to the DAO just like we did with the find all method for getting a list of 5:46 tasks using the currently authenticated users ID, check the teacher's notes. 5:49 There are options for this. 5:54 Well since we now have a to do item on our list for 5:57 discussing security concerns let's do that now. 6:01 First a word of caution, this discussion is not meant to be exhaustive. 6:05 There is a plethora of security vulnerabilities that 6:11 need to be taken into consideration when developing a web application. 6:14 So please Do your research. 6:17 What we'll talk about here are two simple options that add 6:21 a nice layer of security to our application. 6:24 And that are quickly implemented whispering security. 6:27 The first item I'd like to discuss is the storage of passwords. 6:30 Currently we've stored passwords in the database as plain text, 6:33 such that if a malicious user gain access to the database, 6:38 whether through our application or not we'd be in trouble. 6:41 Let me show you here in IntelliJ. 6:46 We insert those passwords very clearly as plain text. 6:48 Even if they're not strong passwords they are stored exactly as entered. 6:54 Now should our database become compromised, 7:00 a simple query reveals plaintext usernames and plaintext passwords. 7:02 As a responsible developer you should take necessary steps to ensure,to 7:07 the greatest extent possible, that the data you depend on can't be used. 7:11 Maliciously. 7:15 Knowing that people often use the same passwords for 7:17 many if not all web applications, a data breach might have consequences 7:19 that stretch far beyond the boundaries of your application. 7:24 In short be responsible developers. 7:27 What we should be doing here is storing encrypted versions of passwords 7:31 where it is practically impossible to decrypt the encrypted version and 7:35 get back at the original password. 7:39 That is, it's a one way street. 7:42 Now I want to be clear that this isn't a workshop on encryption algorithms, so 7:44 you can do your own research as to which encrypted method you'd like to use and 7:48 how you'd like to customize it. 7:52 In this application we'll use what's called the b crypt hashing function. 7:54 Check the teacher's notes for more info on this method. 7:59 As spring provides an implementation called the b crypt password encoder. 8:02 So let's switch to our security config class and 8:06 set that up in our config package. 8:09 I will open security config. 8:12 Let me collapse this panel here so I have more room. 8:13 We'll start by creating a password in code or being in this class and I will do that. 8:19 I wanna do that right here. 8:26 Not all that matters. 8:30 So I'll say public password encoder, 8:33 I'll call it password encoder and I will return a new 8:38 BCrypt password encoder and we will use strength 10. 8:45 Again check the teachers notes and 8:50 do your own research as to what this exactly means. 8:53 So then back up in this method, in configuring the authentication 8:57 manager builder, we'll set the password encoder as follows. 9:02 So right after we set the user details service, 9:07 we will set the password encoder to what the password encoder being. 9:10 Now what will happen is that every time authentication takes place. 9:17 The submitted password will being coded. 9:20 And the encoded version will be checked against the database 9:22 instead of the plain password being checked. 9:25 Of course, this means that passwords will have to have been stored into 9:27 the database as in coded or hashed passwords. 9:31 So we'll need to alter our import.SQL file, we'll need 9:34 to replace these values with their hashed versions or their encrypted versions. 9:39 Now to get a hash for these passwords, you can hit up any number of online sources. 9:45 So let me just switch to Chrome. 9:49 And, and I will, in a new tab, Google, bcrypt. 9:52 Hash generator. 9:58 And I will choose will say this one right here. 10:02 Cool. 10:07 Enter the String to be encrypt. 10:07 So I will be encrypt password. 10:09 And there's the hash right there. 10:13 So what I wanna do is copy this entire String. 10:15 Just like that. 10:20 And I want to paste it in place of my plain text passwords here. 10:21 Just like this. 10:25 Now, whenever I include hash passwords for 10:28 initial data, I'm always careful to leave a comment about the plain text passwords 10:31 that developers will need to use to log in to the application. 10:35 Because he can't enter the hash in the password field of the web app. 10:38 So this is just a note to developers. 10:42 Passwords are both password. 10:44 There's no way for a developer to know otherwise 10:50 that this is actually the encrypted version of the password. 10:54 Password, so I leave a comment there for development purposes. 11:00 Now let's run the application and 11:05 make sure it works with our encrypted passwords. 11:07 So let me pop this open again I'll stop our previous instance and 11:09 I will rerun that boot run task. 11:12 Looks like everything compiled correctly. 11:17 And after just a couple moments, the application has started successfully. 11:21 So, back in our application, let's refresh and 11:25 let's make sure that you are using the username and password. 11:28 That is the hashed password on the database side, 11:32 will still allow me to successfully login and looks like it worked. 11:35 So the advantage is that now we don't have users password stored plainly anywhere. 11:40 And if a malicious user got ahold of our user table, we can have more confidence 11:45 that passwords won't be decrypted, but we can never be absolutely certain, 11:49 but this increased level of security is critical. 11:54 Alright as a final exercise, let's add CSRF protection to our app. 11:58 CSRF or commonly said, Caesar, stands for Cross Site Request Forgery, and it happens 12:04 when your application gets a request from a user that the application trusts. 12:10 Which is to say in our application the app receives a request from a user's browsing 12:14 session which would pass along the jsessionid cookie. 12:18 Thereby granting the request whatever authentication privileges are associated 12:22 with that jsessionid. 12:26 So how can we protect against the damaging affects of this. 12:28 Now the first approach is to stop using get requests for 12:32 anything that changes server's state. 12:35 One can certainly code an application that can change database data or 12:37 other server resources from a get request. 12:41 But this goes against HTTP specifications. 12:43 And though those specs aren't enforced, they are there for a reason. 12:46 As for those post requests, which do change server data, 12:50 we can add C.S.R.F. or csrf protection to our app. 12:54 Let me show you how you can turn this on for spring, 12:58 and then I'll show you the effect it has. 13:00 So, to add this protection, we'll open our security config class. 13:02 Collapse this again. 13:07 Let's scroll down to our security filter chain right here and 13:09 after the log out configuration we'll continue the chain by adding 13:14 and followed by c serve. 13:18 There it is right there. 13:24 And that's all that's needed to add cserve of protection into our application. 13:28 So let's fire this up and see what effect this has had. 13:33 I will stop the previous instance and rerun. 13:36 Compiled successfully. 13:40 And booted successfully, so let's refresh this. 13:46 Now we see the same login form that we've been seeing all along. 13:51 But it is actually different. 13:54 Let's inspect the form and see what has Changed. 13:57 If you look at the generated markup you'll see a hidden input right here. 14:02 With the name_cerf and its randomly generated value. 14:07 On the server this value will be saved in session data and 14:13 will be compared to the value that's passed with the form submission. 14:17 If the value in the submission is different from the server side session 14:20 data, the request will be rejected. 14:24 And since it would be highly unlikely that another website open in the same 14:27 browsing session, would somehow come up with this value, 14:31 this serves as a nice protection against these sea-surf attacks. 14:34