WEBVTT

0:00:03.420000 --> 0:00:06.440000
 Hello everyone and welcome to this video.


0:00:06.440000 --> 0:00:10.620000
 In this video we're going to be tying
 off the encoding section of this

0:00:10.620000 --> 0:00:15.460000
 course by taking a look
 at base64 encoding.

0:00:15.460000 --> 0:00:20.800000
 So base64 encoding with regards to where
 it falls in terms of web applications

0:00:20.800000 --> 0:00:28.780000
 and the encoding process typically falls
 into the again very similar space

0:00:28.780000 --> 0:00:36.680000
 as HTML encoding where it essentially
 involves the encoding of data like

0:00:36.680000 --> 0:00:43.940000
 typically data like images or multimedia
 into a base64 format for various

0:00:43.940000 --> 0:00:46.260000
 reasons of which I'll actually dive into.


0:00:46.260000 --> 0:00:50.820000
 So in the previous video when we were
 taking a look at URL encoding that

0:00:50.820000 --> 0:00:55.340000
 was specifically used for the transmission
 of data as I highlighted quite

0:00:55.340000 --> 0:01:00.500000
 a lot. We're now again taking a look
 at another important type of encoding

0:01:00.500000 --> 0:01:04.760000
 that you're likely to encounter if
 you haven't already which is base64

0:01:04.760000 --> 0:01:09.700000
 encoding. So what is base64 encoding?

0:01:09.700000 --> 0:01:14.540000
 Base64 encoding is a method or technique
 that is used to encode binary

0:01:14.540000 --> 0:01:20.560000
 data such as images, audio files and
 other non textual data although it

0:01:20.560000 --> 0:01:25.680000
 can be extended to textual data
 into a text based format.

0:01:25.680000 --> 0:01:30.140000
 This encoding is commonly used to represent
 binary data in contexts where

0:01:30.140000 --> 0:01:32.820000
 only textual data is supported.

0:01:32.820000 --> 0:01:38.920000
 So let's say you know like HTML file
 or in the case of this example such

0:01:38.920000 --> 0:01:48.740000
 as within email binary data into a
 set of ASCII characters allowing it

0:01:48.740000 --> 0:01:51.500000
 to be safely transmitted as text.

0:01:51.500000 --> 0:01:56.220000
 Now speaking specifically
 about base64 what is it?

0:01:56.220000 --> 0:02:00.740000
 Base64 is an encoding schema alright
 and in terms of its character set

0:02:00.740000 --> 0:02:07.440000
 base64 encoding utilizes a set of 64
 different characters hence the name

0:02:07.440000 --> 0:02:12.540000
 base64. These characters consist of
 letters both uppercase and lowercase

0:02:12.540000 --> 0:02:18.740000
 digits and two additional characters
 often a plus and a forward slash.

0:02:18.740000 --> 0:02:23.080000
 Different variations of base64 encoding
 may use different characters for

0:02:23.080000 --> 0:02:28.040000
 the last two positions like the equal
 sign and in terms of its padding

0:02:28.040000 --> 0:02:34.140000
 since binary data might not be evenly
 divisible by three padding is used

0:02:34.140000 --> 0:02:37.780000
 to make the encoded data a multiple
 of four characters.

0:02:37.780000 --> 0:02:43.260000
 The padding character often the equals
 symbol or the equal sign is added

0:02:43.260000 --> 0:02:49.580000
 to the end of the encoded string and
 other characteristics are the three

0:02:49.580000 --> 0:02:54.660000
 to four mapping so base64 encoding operates
 on chunks of three bytes which

0:02:54.660000 --> 0:02:59.440000
 you know comprise of 24 bits from
 the original binary data.

0:02:59.440000 --> 0:03:05.500000
 These 24 bits are split into four six
 bit units which correspond to four

0:03:05.500000 --> 0:03:07.800000
 base64 characters.

0:03:07.800000 --> 0:03:11.620000
 The conversion table is fairly easy
 to understand the 64 characters in

0:03:11.620000 --> 0:03:17.240000
 the base64 character set are used as a
 mapping table each of the 64 characters

0:03:17.240000 --> 0:03:23.200000
 corresponds to a specific six bit value
 and in terms of the encoding process

0:03:23.200000 --> 0:03:27.320000
 it works it's fairly easy to understand
 so you know you take a chunk of

0:03:27.320000 --> 0:03:31.620000
 three bytes from the binary data split
 these three bytes into four six

0:03:31.620000 --> 0:03:37.600000
 bit segments map each six bit a segment
 to its corresponding base64 character

0:03:37.600000 --> 0:03:42.600000
 concatenate the base64 characters to create
 a segment of the encoded string

0:03:42.600000 --> 0:03:47.020000
 if padding is needed add padding characters
 at the end of the encoded

0:03:47.020000 --> 0:03:51.640000
 segment and in terms of decoding fairly
 simple as well base64 decoding

0:03:51.640000 --> 0:03:57.040000
 is just the reverse of the encoding process
 the encoding the encoded base64

0:03:57.040000 --> 0:04:01.500000
 string is divided into segments of four
 characters each character is converted

0:04:01.500000 --> 0:04:06.300000
 back to its six bit value and these
 values are combined to reconstruct

0:04:06.300000 --> 0:04:08.980000
 the original binary data.

0:04:08.980000 --> 0:04:14.000000
 In terms of some of the other characteristics
 the binary data in text

0:04:14.000000 --> 0:04:19.920000
 context web applications often deal with
 binary data such as images audio

0:04:19.920000 --> 0:04:25.900000
 or files since URLs HTML and other text
 based formats can't directly handle

0:04:25.900000 --> 0:04:32.520000
 binary data base64 encoding is used to
 represent this binary data as text

0:04:32.520000 --> 0:04:37.340000
 this allows binary data to be included
 in places that expect text such

0:04:37.340000 --> 0:04:42.240000
 as HTML or JSON responses it's frequently
 used if you've ever utilized

0:04:42.240000 --> 0:04:47.560000
 or taken a look at the source code
 of a particular web application in

0:04:47.560000 --> 0:04:53.740000
 modern web applications base64 is utilized
 to encode images or icons for

0:04:53.740000 --> 0:04:59.900000
 the inclusion in HTML and some other
 use cases around data URL embedding

0:04:59.900000 --> 0:05:03.840000
 so data URLs are a way to embed small
 resources which is what I was talking

0:05:03.840000 --> 0:05:09.640000
 about directly into the HTML or CSS
 code these URLs include the actual

0:05:09.640000 --> 0:05:15.420000
 resource data in base64 encoded form
 eliminating the need for separate

0:05:15.420000 --> 0:05:20.260000
 HTTP requests for those additional
 requests so this is usually done to

0:05:20.260000 --> 0:05:23.840000
 make the web application load much
 faster so let's say your HTML page

0:05:23.840000 --> 0:05:27.980000
 requires a set of images whenever you
 reference when you say you open

0:05:27.980000 --> 0:05:34.060000
 up a tag the a tag so you say a href
 equals you would put in the location

0:05:34.060000 --> 0:05:37.480000
 of that resource it could either be
 stored locally so you'd then just

0:05:37.480000 --> 0:05:42.700000
 say image.png however it is if it is
 being loaded externally let's say

0:05:42.700000 --> 0:05:48.560000
 from an AWS as three bucket you would
 have to reference the URL to that

0:05:48.560000 --> 0:05:52.400000
 particular resource now what you can
 do is take the source of that image

0:05:52.400000 --> 0:05:57.280000
 and still reference it in URL format
 but just base64 encoded so these

0:05:57.280000 --> 0:06:02.040000
 URLs will include the actual resource data
 in base64 encoded form eliminating

0:06:02.040000 --> 0:06:06.840000
 the need for separate HTTP requests
 what that means is that you're now

0:06:06.840000 --> 0:06:13.160000
 removing that additional overhead in
 terms of network performance by the

0:06:13.160000 --> 0:06:18.640000
 web application by just having everything
 in a single HTML page so for

0:06:18.640000 --> 0:06:23.300000
 an example an image can be embedded
 directly in HTML using data using

0:06:23.300000 --> 0:06:28.220000
 a data URL and I'll be using an example
 to demonstrate this the other

0:06:28.220000 --> 0:06:31.840000
 use cases are again tie into what I
 explained earlier the minimization

0:06:31.840000 --> 0:06:37.880000
 of requests so by encoding small images
 or icons as data URLs within CSS

0:06:37.880000 --> 0:06:43.600000
 or HTML web developers can reduce the
 number of requests made to the server

0:06:43.600000 --> 0:06:48.060000
 potentially and that's the key word potentially
 improving page load times

0:06:48.060000 --> 0:06:53.060000
 another use case is simplification of resource
 management embedding resources

0:06:53.060000 --> 0:06:58.420000
 directly into HTML or CSS can simplify
 resource management and deployment

0:06:58.420000 --> 0:07:07.320000
 developers don't need to worry about certain
 offline or single page applications

0:07:07.320000 --> 0:07:13.960000
 base64 encoded data can be stored in
 local storage or indexed DB for quick

0:07:13.960000 --> 0:07:19.200000
 access without the need to fetch resources
 from the actual server so we'll

0:07:19.200000 --> 0:07:23.320000
 be using sort of a similar use case
 or example to essentially prove my

0:07:23.320000 --> 0:07:27.680000
 point now you may have a question on
 your mind and that is why is this

0:07:27.680000 --> 0:07:31.460000
 important in the context of web application
 security or web application

0:07:31.460000 --> 0:07:36.620000
 penetration testing well it's important
 to understand because you need

0:07:36.620000 --> 0:07:41.500000
 to understand why web application developers
 utilize it and the different

0:07:41.500000 --> 0:07:45.300000
 ways they would utilize base64 encoding
 because that could open up you

0:07:45.300000 --> 0:07:50.120000
 know potential misconfigurations or
 vulnerabilities overall it's very

0:07:50.120000 --> 0:07:54.320000
 important to understand what you see
 when you analyze source code and

0:07:54.320000 --> 0:07:58.420000
 in this particular case as I said base64
 encoding is used quite a lot

0:07:58.420000 --> 0:08:02.000000
 in modern web applications for various
 reasons that I've just outlined

0:08:02.000000 --> 0:08:08.760000
 so again to end or to for the reasons
 or for the demonstration of the

0:08:08.760000 --> 0:08:13.640000
 this example again there is no live
 lab you can pretty much do this on

0:08:13.640000 --> 0:08:18.540000
 your own the reasons are self-explanatory
 when we get into the next section

0:08:18.540000 --> 0:08:23.440000
 we will be talking about filtering
 we will have live labs but for now

0:08:23.440000 --> 0:08:27.300000
 I'll just be showing you two examples
 you know firstly showing you how

0:08:27.300000 --> 0:08:31.160000
 the process works and then giving you
 a you know real world example as

0:08:31.160000 --> 0:08:36.340000
 to you know how how images are you
 know essentially encoded in base64

0:08:36.340000 --> 0:08:41.420000
 and then included or embedded in an
 HTML page so with that being said

0:08:41.420000 --> 0:08:45.000000
 let me switch over to my calilinic
 system and let's get started with a

0:08:45.000000 --> 0:08:50.720000
 demo all right so I am back on my calilinic
 system and for the purposes

0:08:50.720000 --> 0:08:55.840000
 of simplicity I've already created the
 sample web app the first example

0:08:55.840000 --> 0:09:00.840000
 that'll just do what we've done previously
 take input from a user and

0:09:00.840000 --> 0:09:06.040000
 then encode that into base64 and display
 the base64 encoded format and

0:09:06.040000 --> 0:09:09.340000
 then we'll take a look at the other
 example which will essentially allow

0:09:09.340000 --> 0:09:14.460000
 us to upload an image that image will
 then be base64 encoded and then

0:09:14.460000 --> 0:09:18.540000
 you know embedded on the page and that'll
 sort of highlight one of the

0:09:18.540000 --> 0:09:23.920000
 use cases of base64 encoding with regards
 to modern web applications so

0:09:23.920000 --> 0:09:29.460000
 I'm going to save this here as a I'll
 just call it index.html and this

0:09:29.460000 --> 0:09:32.960000
 will not require you know a web server
 like Apache we can just go into

0:09:32.960000 --> 0:09:40.500000
 my terminal here and I'll just say sudo
 python 3 m http.server and we'll

0:09:40.500000 --> 0:09:47.080000
 open it up the web server on port 80
 as always you always need to disable

0:09:47.080000 --> 0:09:51.040000
 Apache 2 so I'm just going to disable
 Apache 2 like so and then run the

0:09:51.040000 --> 0:09:55.380000
 previous code here or on the previous
 command sorry and now I'll just

0:09:55.380000 --> 0:10:00.740000
 navigate to 127.0.0.1 and there we are
 so this is the web app very very

0:10:00.740000 --> 0:10:05.500000
 simple we just type in you know some
 text here like Alexis and we encode

0:10:05.500000 --> 0:10:10.560000
 it and that's the base64 encoded version
 of my name now this can also

0:10:10.560000 --> 0:10:15.640000
 be done from your terminal so for example
 I can say echo Alexis and I

0:10:15.640000 --> 0:10:22.320000
 say base64 I pipe it to base64 the base64
 command and the point is that

0:10:22.320000 --> 0:10:28.360000
 this should be added or should be the
 same here so if I go into the web

0:10:28.360000 --> 0:10:33.100000
 app here you can see that is displayed
 however the padding which is you

0:10:33.100000 --> 0:10:38.180000
 know two equals sign or the inclusion
 of the two equal symbols is not

0:10:38.180000 --> 0:10:42.640000
 included here and that again is by design
 because I pretty much stripped

0:10:42.640000 --> 0:10:47.540000
 that out of the output in the web application
 but the point is that the

0:10:47.540000 --> 0:10:52.980000
 great thing with base64 is that the encoding
 and decoding is standardized

0:10:52.980000 --> 0:10:57.720000
 because of the schema that is utilized
 which means that whatever is encoded

0:10:57.720000 --> 0:11:02.020000
 whether be coming from the client side
 or the server side can easily be

0:11:02.020000 --> 0:11:09.560000
 decoded to get the same value so the
 bottom line here is that if I take

0:11:09.560000 --> 0:11:13.900000
 this now and I want it to decode it
 I can easily even do that through

0:11:13.900000 --> 0:11:19.100000
 my terminal so I can say echo just put
 that in here and I say pipe that

0:11:19.100000 --> 0:11:23.580000
 to base64 and specify that I want to
 decode it and there we go so the

0:11:23.580000 --> 0:11:27.840000
 padding is just added as I said earlier
 on in the slides there you know

0:11:27.840000 --> 0:11:33.340000
 for padding reasons and there you go
 so that's one of the great you know

0:11:33.340000 --> 0:11:37.360000
 use cases of base64 or one of the reasons
 why it's utilized is because

0:11:37.360000 --> 0:11:42.400000
 encoding and decoding is fairly standardized
 so again this is not a hashing

0:11:42.400000 --> 0:11:49.000000
 algorithm it's just an encoding system
 that is fairly useful so now I'm

0:11:49.000000 --> 0:11:52.700000
 going to just copy over another piece
 or another web application here

0:11:52.700000 --> 0:11:57.280000
 that again will utilize JavaScript
 and the way this works is going to

0:11:57.280000 --> 0:12:01.320000
 be very very simple as well we're just
 going to call this base64.html

0:12:01.320000 --> 0:12:08.520000
 and the way it works is very very simple
 we're just going to we've just

0:12:08.520000 --> 0:12:12.220000
 created an image upload form here that
 again allows you to upload an image

0:12:12.220000 --> 0:12:17.240000
 or allows a user to upload an image and
 then pretty much utilizing JavaScript

0:12:17.240000 --> 0:12:23.800000
 it will convert that image into base64
 and will then display the image

0:12:23.800000 --> 0:12:30.380000
 and I'll then show you how you know
 it can be embedded so the point is

0:12:30.380000 --> 0:12:38.120000
 let me go in here and we'll say you
 know base64.html like so and that

0:12:38.120000 --> 0:12:42.540000
 should actually exist let me start up
 the web server again there we are

0:12:42.540000 --> 0:12:48.660000
 that's why it wasn't loading up and
 we pretty much called it base64.html

0:12:48.660000 --> 0:12:54.260000
 I believe yes we did in terms of the
 terminal this is still on the desktop

0:12:54.260000 --> 0:13:00.920000
 that should work actually no we do not
 want HTTPS there we are so we just

0:13:00.920000 --> 0:13:04.760000
 browse for an image and I'll just go into
 pictures upload an i-n-e wallpaper

0:13:04.760000 --> 0:13:11.080000
 upload and display it and now if we view
 the actual source of this particular

0:13:11.080000 --> 0:13:16.280000
 page you can see that yeah so it just
 contains the actual script here

0:13:16.280000 --> 0:13:21.960000
 so that's dynamically being appended but
 what we could what you'll typically

0:13:21.960000 --> 0:13:28.540000
 see happening is the actual image will
 if you want to embed it in terms

0:13:28.540000 --> 0:13:34.880000
 of embedding an image in html in base64
 format is fairly easy to do what

0:13:34.880000 --> 0:13:41.200000
 you need to do is pretty much firstly
 base64 encode the image right and

0:13:41.200000 --> 0:13:45.900000
 then secondly to embed it you just
 use the i-m-g tag or the source tag

0:13:45.900000 --> 0:13:50.820000
 and specify that it's a you know data
 URL so to do that we just go back

0:13:50.820000 --> 0:13:57.560000
 to this web application here you can
 see that base64 var base64 image

0:13:57.560000 --> 0:14:03.180000
 and then create that's displayed here
 create an image element and set

0:14:03.180000 --> 0:14:10.560000
 its source to base64 data we can actually
 use that same variable here

0:14:10.560000 --> 0:14:16.600000
 and what we can do is pretty much just
 try and include that in here and

0:14:16.600000 --> 0:14:27.940000
 say for example we can just say you
 know for example here so img src is

0:14:27.940000 --> 0:14:38.560000
 equal to and we then say data and image
 is going to be you know png base64

0:14:38.560000 --> 0:14:44.620000
 and we essentially would get the value
 and put in the base64 value of

0:14:44.620000 --> 0:14:50.440000
 the image here so what that means is that
 you know for example if i navigate

0:14:50.440000 --> 0:14:56.780000
 into let me open up a new tab here and
 i navigate into cd pictures right

0:14:56.780000 --> 0:15:06.340000
 over here i can say you know base 64
 i-n-e wallpaper 1a.jpg that will

0:15:06.340000 --> 0:15:11.100000
 give me the value there and i can then
 include it if i wanted if i so

0:15:11.100000 --> 0:15:14.640000
 wanted this is quite a large image so
 let's go for a much smaller image

0:15:14.640000 --> 0:15:18.440000
 here let me see if i can save an image
 from another website like the w3

0:15:18.440000 --> 0:15:25.780000
 logo here sorry not the i didn't want
 the URL i want the image so actually

0:15:25.780000 --> 0:15:30.540000
 hold on that's being rendered i can
 just open it up in a new tab here

0:15:30.540000 --> 0:15:37.940000
 or let me find another image here like
 just search for an icon or let

0:15:37.940000 --> 0:15:42.140000
 me find another image that i can use
 maybe from a website so i can say

0:15:42.140000 --> 0:15:51.220000
 in this particular case let's actually
 view the source here i don't want

0:15:51.220000 --> 0:15:59.860000
 to see the selection source if i say
 view source and in this particular

0:15:59.860000 --> 0:16:04.480000
 case it's still referencing the the
 actual image but i'll save the image

0:16:04.480000 --> 0:16:13.420000
 here as a desktop as we'll just say
 icon icon not png on my desktop and

0:16:13.420000 --> 0:16:23.500000
 again i'll just navigate to my say
 base 64 and i'll say icon.png there

0:16:23.500000 --> 0:16:29.920000
 we are and now i could just easily
 include it in my web page and there

0:16:29.920000 --> 0:16:33.140000
 we are let me just go back into the
 source code in fact we can pretty

0:16:33.140000 --> 0:16:38.340000
 much get rid of all of this here pretty
 much the javascript code and just

0:16:38.340000 --> 0:16:48.900000
 and just display it using the i-m-g
 to rid of this as well and just say

0:16:48.900000 --> 0:16:59.060000
 you know i-m-g source is equal to a
 data image and this is a png so the

0:16:59.060000 --> 0:17:07.480000
 png is base 64 and then we'll just paste
 it we'll use a comma as a delimiter

0:17:07.480000 --> 0:17:12.900000
 and sorry let me make sure i've typed
 that in correctly comma as a delimiter

0:17:12.900000 --> 0:17:17.520000
 and from that point on we can just
 close the image tag but you'd need

0:17:17.520000 --> 0:17:22.060000
 to obviously close the concatenation
 there so we'll just say alt is equal

0:17:22.060000 --> 0:17:29.320000
 to icon and you know we can just close
 the tag there so now we go into

0:17:29.320000 --> 0:17:34.080000
 the web server we know it's still running
 here on the actual desktop so

0:17:34.080000 --> 0:17:39.380000
 now let's just go back to that web page
 and base 64.html and you can see

0:17:39.380000 --> 0:17:44.620000
 we were able to embed it so the great
 thing is now i actually don't need

0:17:44.620000 --> 0:17:48.680000
 this file stored on my system and to
 prove my point i can actually just

0:17:48.680000 --> 0:17:53.660000
 go and sorry not open up a terminal but
 open up my file explorer and i'll

0:17:53.660000 --> 0:17:58.620000
 just delete the actual icon because
 we've converted it to base 64 we're

0:17:58.620000 --> 0:18:02.480000
 not making a request for that image anymore
 there we are you can see because

0:18:02.480000 --> 0:18:07.700000
 we've already included it in the source
 code just in base 64 encoded format

0:18:07.700000 --> 0:18:13.080000
 now the reason it's used is because
 html will not allow binary data so

0:18:13.080000 --> 0:18:19.280000
 for example if i go into the image
 here let me go back into the trash

0:18:19.280000 --> 0:18:26.600000
 and i let me just restore it right and
 i actually open this up with let's

0:18:26.600000 --> 0:18:33.440000
 say a text editor which i think i'll
 just do using the terminal so i'll

0:18:33.440000 --> 0:18:41.320000
 just say cat image sorry icon.png you
 can see this is binary data we cannot

0:18:41.320000 --> 0:18:47.960000
 pass in binary data in html right so
 that's where base 64 comes into play

0:18:47.960000 --> 0:18:52.040000
 and as i said this is a technique that
 is frequently utilized and if i

0:18:52.040000 --> 0:18:57.320000
 start up the web server again we can
 actually explore the speed in terms

0:18:57.320000 --> 0:19:03.720000
 of the actual difference in speed so
 point is let's create another IMG

0:19:03.720000 --> 0:19:10.160000
 tag here that will essentially that'll
 essentially load the same image

0:19:10.160000 --> 0:19:16.960000
 but it'll be loaded locally so we'll
 just call this IMGSRC is just icon

0:19:16.960000 --> 0:19:23.320000
.png right so we're loading it locally
 as we would normally and i'm just

0:19:23.320000 --> 0:19:31.900000
 going to comment this here right now
 so first things first if i now reload

0:19:31.900000 --> 0:19:36.520000
 the page i want you to pay attention
 to one thing let me open up inspect

0:19:36.520000 --> 0:19:41.400000
 here and i'll go into network and i want
 you to take a look at the number

0:19:41.400000 --> 0:19:46.560000
 of requests when we make a request
 you can see that in this particular

0:19:46.560000 --> 0:19:51.740000
 case this is the favicon that's perfectly
 fine but you can see that get

0:19:51.740000 --> 0:19:57.080000
 request here because it's still included
 in the code let me just get rid

0:19:57.080000 --> 0:20:02.820000
 of it here because it's still looking
 for it but let me reload it now

0:20:02.820000 --> 0:20:08.540000
 you can see there we are so just base
 64.html is being loaded so just

0:20:08.540000 --> 0:20:14.800000
 the the html resource is being loaded
 the favicon here is i think making

0:20:14.800000 --> 0:20:21.840000
 reference to a favicon for the web server
 but now if we reverse that and

0:20:21.840000 --> 0:20:27.320000
 let's get rid of the comments here
 and we'll now get rid of this base

0:20:27.320000 --> 0:20:33.100000
 64 image and we now refresh you'll
 see that an additional request will

0:20:33.100000 --> 0:20:38.640000
 be made for that resource so there
 we are you can see that right over

0:20:38.640000 --> 0:20:42.860000
 here the icon is requested because we're
 now making reference to it being

0:20:42.860000 --> 0:20:47.400000
 stored locally with base 64 it's much
 better because you can easily embed

0:20:47.400000 --> 0:20:52.240000
 it and now if we monitor the actual
 speed you can see that finished in

0:20:52.240000 --> 0:20:56.200000
 333 milliseconds which is quite fast
 because this page is very simple

0:20:56.200000 --> 0:21:03.340000
 but if we use base 64 i'm i think it'll
 be much faster we'll see together

0:21:03.340000 --> 0:21:08.220000
 there we are so 285 milliseconds so that's
 why web developers use it because

0:21:08.220000 --> 0:21:13.700000
 it's much faster than making additional
 HTTP requests for additional resources

0:21:13.700000 --> 0:21:18.060000
 which is why even in certain cases
 it's always you know recommended to

0:21:18.060000 --> 0:21:24.420000
 load or to include CSS inline instead
 of you know referencing external

0:21:24.420000 --> 0:21:29.340000
 style sheets because that is usually
 what makes your web application take

0:21:29.340000 --> 0:21:33.640000
 a whole lot longer to load especially
 if you're using a CDN that's always

0:21:33.640000 --> 0:21:40.620000
 unreliable so that's just how i learned
 web application development let

0:21:40.620000 --> 0:21:56.040000
 me just go back here here we are okay
 so you get the idea that's been

0:21:56.040000 --> 0:21:59.800000
 cached for the first time but that's
 how web application developers are

0:21:59.800000 --> 0:22:05.700000
 able to use base 64 to in base 64 encoding
 to embed and you can sort of

0:22:05.700000 --> 0:22:10.080000
 see the advantages from a web app and
 testers perspective the only thing

0:22:10.080000 --> 0:22:14.460000
 that i want to point out is when you
 see this here just understand what

0:22:14.460000 --> 0:22:20.900000
 it means it just means that base 64 encoding
 is being used to maybe embed

0:22:20.900000 --> 0:22:25.000000
 you know binary data that you know could
 not be embedded previously and

0:22:25.000000 --> 0:22:28.840000
 base 64 is what is making it possible
 with that being said that is going

0:22:28.840000 --> 0:22:34.100000
 to conclude the practical demonstration
 side of this video all right so

0:22:34.100000 --> 0:22:39.180000
 that is base 64 encoding and that brings
 us to the end of the encoding

0:22:39.180000 --> 0:22:44.120000
 section of this course now that we have
 an understanding as to what encoding

0:22:44.120000 --> 0:22:48.060000
 is all about you should have a much
 better understanding as to how you

0:22:48.060000 --> 0:22:51.580000
 know how encoding is handled on the web
 and you know how it is implemented

0:22:51.580000 --> 0:22:55.540000
 in web applications we're now going
 to turn our attention to filtering

0:22:55.540000 --> 0:23:00.060000
 which is where the whole idea of input
 filtering and sanitization comes

0:23:00.060000 --> 0:23:05.520000
 into play which as you can expect is all
 about security or security mechanisms

0:23:05.520000 --> 0:23:09.640000
 that are put in place to prevent attacks
 like cross-site scripting, javascript

0:23:09.640000 --> 0:23:15.160000
 sorry SQL injection etc so that's what
 we'll be taking a look at in the

0:23:15.160000 --> 0:23:20.380000
 next section as well as you know how
 to bypass you know input filtering

0:23:20.380000 --> 0:23:24.660000
 or input sanitization so hopefully you've
 learned a lot in this section

0:23:24.660000 --> 0:23:29.060000
 and I'm sure you're excited to get
 into the actual web app pen testing

0:23:29.060000 --> 0:23:33.080000
 side of things with regards to you know
 filters or with that being said