1 00:00:07,720 --> 00:00:08,650 - [Instructor] Web applications 2 00:00:08,650 --> 00:00:10,580 use many different protocols. 3 00:00:10,580 --> 00:00:14,460 Of course, the most prevalent is HTTP. 4 00:00:14,460 --> 00:00:17,510 This course assumes that you actually have a basic 5 00:00:17,510 --> 00:00:21,090 understanding of internet protocols and their use 6 00:00:21,090 --> 00:00:24,310 but we're actually gonna be going over a quick deep dive 7 00:00:24,310 --> 00:00:28,230 into the components of protocols like HTTP 8 00:00:28,230 --> 00:00:32,010 that you will find in nearly every web application 9 00:00:32,010 --> 00:00:33,200 out there. 10 00:00:33,200 --> 00:00:35,420 So let's look at a few facts and definitions 11 00:00:35,420 --> 00:00:36,503 before we proceed. 12 00:00:38,140 --> 00:00:43,140 The HTTP 1.1 protocol is defined in RFC 7230 through 7235. 13 00:00:47,040 --> 00:00:49,480 In the examples that I'm actually gonna go over, 14 00:00:49,480 --> 00:00:54,200 we actually refer to an HTTP server and whenever we say that 15 00:00:54,200 --> 00:00:56,230 we basically mean a web server. 16 00:00:56,230 --> 00:01:00,153 So basically, I'm gonna be referring to it interchangeable. 17 00:01:01,200 --> 00:01:04,110 When I'm gonna refer to HTTP clients, we're also talking 18 00:01:04,110 --> 00:01:09,110 about browsers, proxies, API's or API clients rather 19 00:01:10,700 --> 00:01:14,420 and any other custom HTTP client program. 20 00:01:14,420 --> 00:01:17,520 Now HTTP is a very simple protocol which is actually 21 00:01:17,520 --> 00:01:21,070 both a good thing and also a bad thing for security 22 00:01:21,070 --> 00:01:22,830 in some cases, right? 23 00:01:22,830 --> 00:01:26,440 Now, HTTP is actually categorized in most cases 24 00:01:26,440 --> 00:01:30,700 as a stateless protocol that does not rely 25 00:01:30,700 --> 00:01:34,190 on any persistent connection for communication. 26 00:01:34,190 --> 00:01:38,800 Basically, an HTTP transaction consist of a single request 27 00:01:38,800 --> 00:01:42,770 from a client to a server, followed by a single response 28 00:01:42,770 --> 00:01:45,230 from that server back to the client. 29 00:01:45,230 --> 00:01:47,210 Now the HTTP protocol is actually different 30 00:01:47,210 --> 00:01:51,230 from other stateful protocols like FTP and SMTP, 31 00:01:51,230 --> 00:01:55,440 things like IMAP and POP because in those cases, 32 00:01:55,440 --> 00:01:58,210 those protocols are actually stateful. 33 00:01:58,210 --> 00:02:00,720 That means that actually sequence of really commands 34 00:02:00,720 --> 00:02:03,903 are actually treated as a single interaction. 35 00:02:04,890 --> 00:02:07,340 So I mentioned HTTP proxies, right? 36 00:02:07,340 --> 00:02:11,080 So basically, in this topology, I'm actually highlighting 37 00:02:11,080 --> 00:02:13,790 a client that is actually sitting behind the proxy. 38 00:02:13,790 --> 00:02:16,340 The proxy is actually connected to the internet 39 00:02:16,340 --> 00:02:18,580 and then the client is actually gonna try to connect 40 00:02:18,580 --> 00:02:21,920 to the web server, in this case the HTTP server 41 00:02:21,920 --> 00:02:23,410 through the proxy. 42 00:02:23,410 --> 00:02:28,330 So basically, HTTP proxies can act both as servers 43 00:02:28,330 --> 00:02:30,620 and also as clients. 44 00:02:30,620 --> 00:02:33,950 Basically, they make request to the web servers 45 00:02:33,950 --> 00:02:37,630 on behalf of other clients sitting behind them. 46 00:02:37,630 --> 00:02:40,870 Now they enable HTTP transfer across firewalls 47 00:02:40,870 --> 00:02:44,910 and they can also provide support for caching as well. 48 00:02:44,910 --> 00:02:49,910 So HTTP proxies can perform caching of HTTP messages. 49 00:02:51,430 --> 00:02:53,880 Now proxies can also perform other roles 50 00:02:53,880 --> 00:02:56,670 in complex environments (talks) actually includes 51 00:02:56,670 --> 00:03:00,270 things like network address translation or NAT, 52 00:03:00,270 --> 00:03:05,190 also filtering of HTTP request, it can block a content. 53 00:03:05,190 --> 00:03:08,220 So for example, you can configure a proxy 54 00:03:08,220 --> 00:03:12,870 to block pornographic sites, you can configure it to block 55 00:03:12,870 --> 00:03:16,060 specific content like social media 56 00:03:16,060 --> 00:03:18,900 or probably playing games online 57 00:03:18,900 --> 00:03:21,903 based on many different features and application awareness. 58 00:03:23,290 --> 00:03:24,980 Now, going back to HTTP, 59 00:03:24,980 --> 00:03:28,580 the HTTP is an application level protocol. 60 00:03:28,580 --> 00:03:33,570 And basically, it uses TCP as the underlying 61 00:03:33,570 --> 00:03:37,033 transport layer protocol for transmitting messages. 62 00:03:37,890 --> 00:03:41,300 Now HTTP users a request-response model, 63 00:03:41,300 --> 00:03:44,750 but basically means that the client program sends 64 00:03:44,750 --> 00:03:49,150 an HTTP request message to a server and then the server 65 00:03:49,150 --> 00:03:52,470 returns an HTTP response message 66 00:03:52,470 --> 00:03:54,023 as I'm actually showing here. 67 00:03:55,180 --> 00:03:59,490 Now whenever HTTP clients or browsers and (talks) 68 00:03:59,490 --> 00:04:02,690 can be different machine to machine communication 69 00:04:02,690 --> 00:04:05,410 like in the case of API's but whenever the clients 70 00:04:05,410 --> 00:04:08,040 and the servers actually communicate to each other, 71 00:04:08,040 --> 00:04:11,900 specifically browsers, they perform interaction 72 00:04:11,900 --> 00:04:14,220 based on headers. 73 00:04:14,220 --> 00:04:19,220 They also perform interaction that includes the body 74 00:04:19,390 --> 00:04:23,890 or the content of those HTTP messages. 75 00:04:23,890 --> 00:04:28,150 Now there are different HTTP methods, there's GET, 76 00:04:28,150 --> 00:04:30,770 which actually retrieves information from a server, 77 00:04:30,770 --> 00:04:33,510 there's also HEAD which basically is the same as GET 78 00:04:33,510 --> 00:04:38,510 but actually returns only HTTP headers and no document body. 79 00:04:38,790 --> 00:04:42,650 There's also the POST method that actually sends data 80 00:04:42,650 --> 00:04:47,650 to the server, typically using HTML forms, API requests 81 00:04:48,210 --> 00:04:50,180 and other mechanisms. 82 00:04:50,180 --> 00:04:55,180 There's also the TRACE method and basically what TRACE does 83 00:04:55,350 --> 00:04:58,900 is that it perform some message loopback test among the path 84 00:04:58,900 --> 00:05:01,130 to the target resource. 85 00:05:01,130 --> 00:05:03,790 Then you also have PUT, which actually uploads 86 00:05:03,790 --> 00:05:07,320 a representation of the specific URI that is actually 87 00:05:07,320 --> 00:05:10,620 being used to communicate to the web server. 88 00:05:10,620 --> 00:05:14,640 There's also DELETE which deletes the specified resource. 89 00:05:14,640 --> 00:05:17,890 There's also OPTIONS that actually returns the HTTP methods 90 00:05:17,890 --> 00:05:19,840 that the server supports. 91 00:05:19,840 --> 00:05:23,600 And there's also CONNECT that basically converts 92 00:05:23,600 --> 00:05:27,733 the request connection to a transparent TCP/IP tunnel. 93 00:05:28,760 --> 00:05:33,760 Now, the URI and the path to resource field represents 94 00:05:33,830 --> 00:05:38,440 the path portion of the requested URL. 95 00:05:38,440 --> 00:05:41,420 There's also the request version number field 96 00:05:41,420 --> 00:05:46,290 and that is specifies the version of the HTTP protocol 97 00:05:46,290 --> 00:05:47,873 that is used by the client. 98 00:05:49,220 --> 00:05:52,030 There's also the user-agent field. 99 00:05:52,030 --> 00:05:56,380 Now the server response includes a three digit status code 100 00:05:56,380 --> 00:06:00,110 and a brief human-readable explanation of the status code. 101 00:06:00,110 --> 00:06:03,330 Now the HTTP status code messages can actually be 102 00:06:03,330 --> 00:06:06,310 in different ranges and these are the ranges, 103 00:06:06,310 --> 00:06:10,960 messages in the 100 range are considered informational, 104 00:06:10,960 --> 00:06:14,410 messages in the 200 range are related 105 00:06:14,410 --> 00:06:19,170 to successful transactions, messages in the 300 range 106 00:06:19,170 --> 00:06:24,170 are related to HTTP redirections, messages in the 400 range 107 00:06:25,640 --> 00:06:30,640 are related to client errors and messages in the 500 range 108 00:06:31,180 --> 00:06:34,660 are related to server errors. 109 00:06:34,660 --> 00:06:37,950 Now, HTTP and other protocols use URLs. 110 00:06:38,980 --> 00:06:40,400 And you're definitely familiar with them 111 00:06:40,400 --> 00:06:42,840 since you actually use them everyday, you actually type 112 00:06:42,840 --> 00:06:46,090 potentially a URL to actually access this course 113 00:06:46,090 --> 00:06:47,690 as we speak. 114 00:06:47,690 --> 00:06:49,870 Now here, what I'm gonna do is I'm gonna explain 115 00:06:49,870 --> 00:06:52,620 the elements of the URL so you can better understand 116 00:06:52,620 --> 00:06:55,580 how to actually abuse some of these parameters 117 00:06:55,580 --> 00:06:59,073 and the elements from an offensive security perspective. 118 00:06:59,970 --> 00:07:03,530 So within that URL, you have the scheme which is actually 119 00:07:03,530 --> 00:07:05,700 the portion of the URL that it designates 120 00:07:05,700 --> 00:07:10,700 the underlying protocol like HTTP, FTP, HTTPS and so on. 121 00:07:11,970 --> 00:07:13,410 That is actually followed by a colon 122 00:07:13,410 --> 00:07:16,670 and two forward slashes and this example, 123 00:07:16,670 --> 00:07:19,743 the scheme is actually set to HTTP. 124 00:07:20,620 --> 00:07:25,080 You also have the host or the IP address for the web server 125 00:07:25,080 --> 00:07:29,660 that is actually being accessed and it usually follows 126 00:07:29,660 --> 00:07:32,930 the colon and two forward slashes and in this case, 127 00:07:32,930 --> 00:07:36,360 of course the host is h4cker.org. 128 00:07:36,360 --> 00:07:38,750 Now, you also have a port which is actually 129 00:07:38,750 --> 00:07:42,080 an optional portion of the URL that designates 130 00:07:42,080 --> 00:07:43,260 the port open. 131 00:07:43,260 --> 00:07:46,040 Now by default, if you have HTTP, that is actually 132 00:07:46,040 --> 00:07:49,390 set to port 80 but in some configurations, 133 00:07:49,390 --> 00:07:52,210 it can be using an alternate port. 134 00:07:52,210 --> 00:07:57,210 Of course, if the URL is actually set to HTTPS to use TLS, 135 00:07:57,370 --> 00:08:01,690 then in that case, the default port is port 443. 136 00:08:01,690 --> 00:08:04,200 And then you have the path and that's actually the path 137 00:08:04,200 --> 00:08:08,100 from the root directory of the server, of the web server 138 00:08:08,100 --> 00:08:09,890 to the desired resource, right? 139 00:08:09,890 --> 00:08:11,710 So in this case, you can actually see that 140 00:08:11,710 --> 00:08:15,377 there's a director or a directory rather called dir. 141 00:08:16,770 --> 00:08:19,370 Now, you also have the path segment parameters, 142 00:08:19,370 --> 00:08:21,580 that's actually the portion of the URL 143 00:08:21,580 --> 00:08:25,550 that includes optional name value pairs, right? 144 00:08:25,550 --> 00:08:29,680 So that is a path segment parameter and basically, 145 00:08:29,680 --> 00:08:32,640 a path segment parameter is typically preceded 146 00:08:32,640 --> 00:08:34,780 by a semicolon. 147 00:08:34,780 --> 00:08:36,900 Depending on the programming language, 148 00:08:36,900 --> 00:08:39,040 of course that may vary. 149 00:08:39,040 --> 00:08:42,850 That actually comes immediately after the path information. 150 00:08:42,850 --> 00:08:47,850 In this example, the path parameter ID is 89. 151 00:08:49,770 --> 00:08:53,880 Then you also have query strings and this is an optional 152 00:08:53,880 --> 00:08:57,390 portion of the URL that contains a name value pair 153 00:08:57,390 --> 00:09:00,080 that represent dynamic parameters associated 154 00:09:00,080 --> 00:09:01,920 with the request. 155 00:09:01,920 --> 00:09:06,920 These parameters basically are common in links for tracking 156 00:09:07,350 --> 00:09:10,400 and context setting purposes. 157 00:09:10,400 --> 00:09:13,080 Now, they may also be produced from variables 158 00:09:13,080 --> 00:09:15,023 in HTML forms as well. 159 00:09:15,890 --> 00:09:18,610 Typically, these query strings are preceded 160 00:09:18,610 --> 00:09:23,610 by a question mark and there's also, you can see equal signs 161 00:09:24,000 --> 00:09:26,783 to separate the name and value pairs. 162 00:09:27,620 --> 00:09:32,240 Then you also can see ampersands that actually marks 163 00:09:32,240 --> 00:09:36,490 the boundaries between the name and the value pairs. 164 00:09:36,490 --> 00:09:39,530 Now in this example, the query string is set to name 165 00:09:39,530 --> 00:09:43,263 equals Omar ampersand x equals true. 166 00:09:44,600 --> 00:09:47,310 The current HTTP versions at the time of recording 167 00:09:47,310 --> 00:09:49,980 are 1.1 and 2.0. 168 00:09:49,980 --> 00:09:54,340 In this example, I'm actually showing an HTTP 1.1 exchange 169 00:09:54,340 --> 00:09:57,670 between a web client and a web server. 170 00:09:57,670 --> 00:09:59,480 So let's take a look at how this works. 171 00:09:59,480 --> 00:10:02,180 Basically, the client actually opens a TCP connection 172 00:10:02,180 --> 00:10:05,640 so of course, there's a TCP three-way handshake there. 173 00:10:05,640 --> 00:10:08,350 Then after that, the client actually tries to retrieve 174 00:10:08,350 --> 00:10:11,330 a page, in this case it's actually trying to get, 175 00:10:11,330 --> 00:10:14,150 so it's sending a GET request for a page 176 00:10:14,150 --> 00:10:17,550 just called omar.html, then there's a response back 177 00:10:17,550 --> 00:10:21,400 from the server then within that page, there was a reference 178 00:10:21,400 --> 00:10:26,400 to a CSS file so a style sheet file called omar_css.css, 179 00:10:29,150 --> 00:10:32,720 then we do a GET request for that, then the server response 180 00:10:32,720 --> 00:10:35,300 coming back from the server. 181 00:10:35,300 --> 00:10:37,830 Then in this case, there was actually a JavaScript 182 00:10:37,830 --> 00:10:41,510 that was also used in the page and then the client 183 00:10:41,510 --> 00:10:44,360 is actually sending a GET request for that script, 184 00:10:44,360 --> 00:10:48,820 so script.js, the server responds back to the client 185 00:10:48,820 --> 00:10:52,990 and then the client renders the website in its browser. 186 00:10:52,990 --> 00:10:54,750 Then after the client renders the website 187 00:10:54,750 --> 00:10:59,750 and there's no other request, the TCP connection is closed. 188 00:11:00,920 --> 00:11:03,580 Now in this example, I'm actually showing an HTTP 2.0 189 00:11:04,430 --> 00:11:08,010 or multiplexing type of connection. 190 00:11:08,010 --> 00:11:10,820 So basically the client opens a TCP connection 191 00:11:10,820 --> 00:11:13,220 so there's TCP three-way handshake. 192 00:11:13,220 --> 00:11:15,500 Basically the same steps, you know, it gets a page, 193 00:11:15,500 --> 00:11:18,450 in this case it's omar.html, there's a response coming back 194 00:11:18,450 --> 00:11:22,300 from the server, then right after that, 195 00:11:22,300 --> 00:11:26,620 it's actually sending two GET requests, one for omar.css 196 00:11:26,620 --> 00:11:29,880 and the other one for the script that we saw earlier. 197 00:11:29,880 --> 00:11:33,733 Now the server sends a response back to the client. 198 00:11:34,590 --> 00:11:37,220 The client renders the website 199 00:11:37,220 --> 00:11:41,060 and the TCP connection remains open. 200 00:11:41,060 --> 00:11:44,870 So in short, web sessions are a sequence of HTTP requests 201 00:11:44,870 --> 00:11:47,840 and response transactions between a web client 202 00:11:47,840 --> 00:11:48,830 and a web server, right? 203 00:11:48,830 --> 00:11:53,460 So these transactions include pre-authentication tasks, 204 00:11:53,460 --> 00:11:56,420 it also includes the authentication process, 205 00:11:56,420 --> 00:11:59,580 session management, access control 206 00:11:59,580 --> 00:12:02,150 and also session finalization. 207 00:12:02,150 --> 00:12:04,910 There are tons of applications that keep track 208 00:12:04,910 --> 00:12:07,980 of information about each user for the duration 209 00:12:07,980 --> 00:12:09,070 of the transaction, right? 210 00:12:09,070 --> 00:12:11,550 So, several web applications have the ability 211 00:12:11,550 --> 00:12:14,930 to establish variables, like access rights 212 00:12:14,930 --> 00:12:16,433 and localization settings. 213 00:12:17,340 --> 00:12:21,240 These variables apply to each and every interaction 214 00:12:21,240 --> 00:12:23,600 a user has with a web application 215 00:12:23,600 --> 00:12:26,390 for the duration of the session. 216 00:12:26,390 --> 00:12:29,330 Now web applications can create sessions to keep track 217 00:12:29,330 --> 00:12:34,330 of anonymous users after the very first user request. 218 00:12:34,830 --> 00:12:37,910 For instance, let's think about an application 219 00:12:37,910 --> 00:12:42,070 that potentially can remember the user language preference 220 00:12:42,070 --> 00:12:46,240 every time that that user visits the site 221 00:12:46,240 --> 00:12:48,430 or the application. 222 00:12:48,430 --> 00:12:53,430 Also, a web application can use a session after the user 223 00:12:53,460 --> 00:12:55,260 actually has authenticated. 224 00:12:55,260 --> 00:12:58,610 This allows the application to identify the user 225 00:12:58,610 --> 00:13:02,100 on any subsequent request and also to be able 226 00:13:02,100 --> 00:13:06,560 to apply security access control to that session. 227 00:13:06,560 --> 00:13:08,840 So in short, web applications can provide 228 00:13:08,840 --> 00:13:13,370 session capabilities both before and after authentication. 229 00:13:13,370 --> 00:13:14,940 Now in the case of authentication, 230 00:13:14,940 --> 00:13:18,450 after an authenticated session has been established, 231 00:13:18,450 --> 00:13:22,970 there's a session ID or a token that is basically 232 00:13:22,970 --> 00:13:25,730 a temporarily equivalent to the strongest 233 00:13:25,730 --> 00:13:28,190 authentication method used by the application. 234 00:13:28,190 --> 00:13:31,750 Now I want to share with you a really good resource 235 00:13:31,750 --> 00:13:33,720 that provides a lot of information 236 00:13:33,720 --> 00:13:35,730 about application authentication 237 00:13:35,730 --> 00:13:38,790 and that is the OWASP authentication sheet 238 00:13:38,790 --> 00:13:40,393 that I'm sharing in the screen. 239 00:13:41,260 --> 00:13:42,730 Now as I mentioned to you (talks), 240 00:13:42,730 --> 00:13:45,480 there's the use of session IDs to keep track 241 00:13:45,480 --> 00:13:46,990 of these sessions, right? 242 00:13:46,990 --> 00:13:50,720 So for instance, you can actually fingerprint 243 00:13:50,720 --> 00:13:54,860 some of these IDs and even trying to determine 244 00:13:54,860 --> 00:13:59,860 what is the protocol or the language or even framework 245 00:14:00,180 --> 00:14:02,220 that is actually being used by the application. 246 00:14:02,220 --> 00:14:04,920 For example, you can easily fingerprint things like 247 00:14:04,920 --> 00:14:09,920 PHP session IDs, JSSE session IDs for in the case of J2EE 248 00:14:11,999 --> 00:14:16,740 and CFID, ColdFusion tokens and many others. 249 00:14:16,740 --> 00:14:19,070 Now, that's why it is recommended to change 250 00:14:19,070 --> 00:14:22,900 the default session ID name of the web developing framework 251 00:14:22,900 --> 00:14:26,920 to a generic name just like you know, just the word ID. 252 00:14:26,920 --> 00:14:29,790 Now, the session ID also must be long enough 253 00:14:29,790 --> 00:14:32,040 to prevent brute force attacks. 254 00:14:32,040 --> 00:14:35,710 Sometimes developers just set it up to just a few bits. 255 00:14:35,710 --> 00:14:39,770 You should actually use long enough session IDs 256 00:14:39,770 --> 00:14:43,570 and also good pseudo random number generators 257 00:14:43,570 --> 00:14:48,570 in order for you to enhance the security and to prevent 258 00:14:48,860 --> 00:14:52,550 of course session prediction attacks, brute force attacks 259 00:14:52,550 --> 00:14:53,383 and many others. 260 00:14:54,560 --> 00:14:59,200 Now there are tons of mechanisms available in HTTP 261 00:14:59,200 --> 00:15:03,250 to maintain session state within web applications, 262 00:15:03,250 --> 00:15:07,876 that includes cookies in the standard HTTP header, 263 00:15:07,876 --> 00:15:12,876 URL parameters, arguments and GET request and others. 264 00:15:13,480 --> 00:15:17,150 Now in addition, web developers use body arguments 265 00:15:17,150 --> 00:15:22,150 and POST request such as hidden form fields or HTML forms 266 00:15:22,550 --> 00:15:24,900 or proprietary HTTP headers. 267 00:15:24,900 --> 00:15:27,670 However, one of the most widely used 268 00:15:27,670 --> 00:15:32,670 session ID exchange mechanisms used nowadays is cookies 269 00:15:33,010 --> 00:15:35,780 which offer a little bit more advanced capability 270 00:15:35,780 --> 00:15:38,150 that is not available in the other methods. 271 00:15:38,150 --> 00:15:42,020 Now, several web development frameworks like ASP.NET, PHP, 272 00:15:42,020 --> 00:15:45,360 Ruby on Rails and many others provide their own 273 00:15:45,360 --> 00:15:49,800 session management features and associated implementations. 274 00:15:49,800 --> 00:15:53,060 It is recommended to use this built-in frameworks 275 00:15:53,060 --> 00:15:55,510 rather than building your own from scratch 276 00:15:55,510 --> 00:15:58,360 since you, they don't reinvent the wheel, 277 00:15:58,360 --> 00:16:01,080 that's the first thing and this frameworks had actually 278 00:16:01,080 --> 00:16:04,190 been tested by many people and they're widely used, right? 279 00:16:04,190 --> 00:16:06,710 So if you try to reinvent the wheel, you're probably 280 00:16:06,710 --> 00:16:09,570 going to lose security problems. 281 00:16:09,570 --> 00:16:12,690 Now whenever you perform pen testing, you're likely to find 282 00:16:12,690 --> 00:16:15,810 people trying to create their own frameworks, right? 283 00:16:15,810 --> 00:16:19,140 So, again, if you're a web developer and you're listening 284 00:16:19,140 --> 00:16:21,570 to this course, please do not do that, 285 00:16:21,570 --> 00:16:23,890 if you're a pen tester, right? 286 00:16:23,890 --> 00:16:27,020 Which most of you are gonna be, then you can actually 287 00:16:27,020 --> 00:16:31,580 take advantage of these flaws of one or many people 288 00:16:31,580 --> 00:16:33,690 actually are trying to implement their own 289 00:16:33,690 --> 00:16:38,040 and they introduce many different security problems. 290 00:16:38,040 --> 00:16:41,540 Now, session management mechanisms based on cookies 291 00:16:41,540 --> 00:16:46,190 can make use of two types of cookies, non-persistent 292 00:16:46,190 --> 00:16:48,880 or session cookies and persistent cookies. 293 00:16:48,880 --> 00:16:53,880 Now, if a cookie has a max-age or expire attribute, 294 00:16:54,090 --> 00:16:57,210 it is considered to be somewhat of a persistent cookie, 295 00:16:57,210 --> 00:16:58,760 that means that it's actually stored on disk 296 00:16:58,760 --> 00:17:02,820 by the web browser until the expiration time. 297 00:17:02,820 --> 00:17:06,620 Common web applications and client will prioritize 298 00:17:06,620 --> 00:17:09,650 the max-age attribute over the expire attribute 299 00:17:09,650 --> 00:17:11,500 so you have to pay attention to that. 300 00:17:12,380 --> 00:17:15,620 Now modern applications typically track users 301 00:17:15,620 --> 00:17:19,800 after authentication by using non-persistent cookies. 302 00:17:19,800 --> 00:17:23,650 This basically forces the session information to be deleted 303 00:17:23,650 --> 00:17:27,010 from the client if the current web browser instance 304 00:17:27,010 --> 00:17:28,610 is closed. 305 00:17:28,610 --> 00:17:30,850 This is why it's extremely important 306 00:17:30,850 --> 00:17:34,550 to use non-persistent cookies so the session ID 307 00:17:34,550 --> 00:17:38,970 does not remain on the web cache or the web client cache 308 00:17:38,970 --> 00:17:40,803 for long periods of time. 309 00:17:41,840 --> 00:17:44,710 Session IDs also must be carefully validated 310 00:17:44,710 --> 00:17:46,780 and verified by an application. 311 00:17:46,780 --> 00:17:49,800 So depending on the session management mechanism, 312 00:17:49,800 --> 00:17:52,110 that, potentially the application is actually using, 313 00:17:52,110 --> 00:17:54,720 the session ID will be received 314 00:17:54,720 --> 00:17:59,250 in a GET or a POST parameter or also can be received 315 00:17:59,250 --> 00:18:03,580 in the URL or in an HTTP header using cookies. 316 00:18:03,580 --> 00:18:07,100 If the web application doesn't validate or filter 317 00:18:07,100 --> 00:18:09,550 invalid session values, they can actually potentially 318 00:18:09,550 --> 00:18:12,300 be used to exploit other web vulnerabilities 319 00:18:12,300 --> 00:18:17,090 like SQL injection, different things 320 00:18:17,090 --> 00:18:20,240 like persistent cross-site scripting if the session IDs 321 00:18:20,240 --> 00:18:23,800 are actually stored in secure manner 322 00:18:23,800 --> 00:18:26,370 and actually reflected back afterwards 323 00:18:29,272 --> 00:18:31,550 by the application and so on. 324 00:18:31,550 --> 00:18:35,310 Now in summary, we review the details of the HTTP protocol 325 00:18:35,310 --> 00:18:40,310 and also how web sessions are created and what are cookies, 326 00:18:41,210 --> 00:18:43,590 what are session IDs and what they're used for. 327 00:18:43,590 --> 00:18:45,614 In the next lessons, you're actually gonna be starting 328 00:18:45,614 --> 00:18:50,220 to gaining some knowledge about the different attacks 329 00:18:50,220 --> 00:18:52,170 against insecure implementations 330 00:18:52,170 --> 00:18:55,733 and different vulnerabilities related to web applications.