Part 4 - HTTP Basics
Video Activity
In the previous video was examined packets. We continue the discussion of web communications by taking a look into the core protocols of web app communications: HTTP and HTTPS. HTTP consists of various types of requests with the fundamental ones by Get, Head, Delete, Post, and Put. The TCP port for HTTP is port 80. The secure version of web app com...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
In the previous video was examined packets. We continue the discussion of web communications by taking a look into the core protocols of web app communications: HTTP and HTTPS. HTTP consists of various types of requests with the fundamental ones by Get, Head, Delete, Post, and Put. The TCP port for HTTP is port 80. The secure version of web app communications is HTTPS and it communicates over TCP port 443. It use SSL/TLS certificates granted by a certificate authority to vouch for the site owner's identity. It also encrypts the data going across the connection for additional security.
Video Transcription
00:03
>> Welcome to Cybrary.
00:03
I'm Raymond Evans and I will
00:03
be your subject matter expert for
00:03
Cybrarian's web application penetration testing course.
00:03
In this video, we will be discussing,
00:03
HTTP and HTTPS basics.
00:03
What will be covered?
00:03
We're going to discuss what is HTTP, what is HTTPS.
00:03
Talk about TCP and discuss
00:03
which one is better HTTP or HTTPS. What is HTTP?
00:03
HTTP is the foundation of
00:03
communication for all web applications and webpages.
00:03
Whenever you're browsing any website,
00:03
you're generating HTTP traffic.
00:03
With that traffic,
00:03
>> you're performing different requests.
00:03
>> Those requests perform different functions.
00:03
We have things like a GET request.
00:03
It retrieves data. Every time you browse to a page,
00:03
you're performing a GET request
00:03
because you're getting the data and it's
00:03
being presented to you in your web browser.
00:03
A HEAD request can be performed as well.
00:03
That's used to get metadata about the pages.
00:03
Certain pieces of software will perform
00:03
HEAD retrievals to get metadata that it may want.
00:03
There's also a DELETE request
00:03
which deletes resources off a server.
00:03
If you don't have a server locked down properly and
00:03
you allow people to perform requests,
00:03
somebody can actually delete resources off your server.
00:03
We have POST request.
00:03
POST request is when there's a submission of
00:03
a web form or something like a forum.
00:03
Then we have PUT request.
00:03
It's used to push resources to a web server.
00:03
Sometimes this can be a bad thing because
00:03
if you don't have a web server locked down properly,
00:03
somebody I could do a PUSH request and push data onto
00:03
the web server and actually
00:03
push something like a piece of malware onto it.
00:03
Now, the malware won't execute.
00:03
However, if you know that exact location that you put
00:03
that item and
00:03
>> you have your social engineering skills up,
00:03
>> then you can actually trick somebody who works with
00:03
those servers into possibly
00:03
browsing to that on the server and executing it.
00:03
You could say that you're somebody
00:03
from whatever company is running that server.
00:03
You can say, "Hey, we've got
00:03
this new update that got pushed out to all the servers,
00:03
except it needs manually executed.
00:03
Can you please go to
00:03
such and such folder and execute such and such file?"
00:03
A lot of times that actually may work due to the fact
00:03
that humans are the weakest link in any network.
00:03
An HTTP uses port 80,
00:03
which is important to know.
00:03
HTTP, when you're browsing different webpages,
00:03
different codes are generated.
00:03
Now you don't see them up front all the time.
00:03
Sometimes they are only in the packets
00:03
>> but they're there.
00:03
>> Things are happening in
00:03
the background that you don't realize.
00:03
If you use a packet analysis tool such as Wireshark,
00:03
then you can actually look at those packets
00:03
and view the different status codes.
00:03
Some examples are the 100 SAS codes,
00:03
which are informational.
00:03
An example of that is the 101 switching protocol.
00:03
Then we have the 200, which are success codes.
00:03
If you successfully browse to a web page and you
00:03
successfully get that data retrieved,
00:03
you'll get a 200 code,
00:03
300 or redirection codes,
00:03
and they give you different information
00:03
about redirection.
00:03
If it's a 301,
00:03
then that web page may have been
00:03
moved to somewhere else, a different URL.
00:03
It's going to redirect you every single time.
00:03
Then there's a classic 404,
00:03
which is a client error code and
00:03
>> 404 is a file not found.
00:03
>> If there's a web page you're looking
00:03
for and that web page doesn't exist anymore,
00:03
you're going to get a 404 not found error.
00:03
Then 500, there's server issues.
00:03
It's things like the 503 code,
00:03
which is service unavailable,
00:03
which means that that server is currently down.
00:03
There's a lot more codes than just these.
00:03
These are just some examples I decide to include,
00:03
so that way you had some idea of the status codes.
00:03
You should definitely look into these codes
00:03
further and understand them better.
00:03
Because if you are using
00:03
a packet analysis tool of something that happened,
00:03
some event that happened in an organization,
00:03
then you will know
00:03
what's going on based on these status codes.
00:03
For example, if a redirection code happens and
00:03
an individual is being redirected
00:03
to a malicious web page,
00:03
you can identify that redirection code in the packets.
00:03
Then we have HTTPS.
00:03
What is HTTPS?
00:03
Well, HTTPS is used for secure communications.
00:03
It uses port 443 and it uses SSL and TLS.
00:03
It uses SSL certificate to
00:03
ensure that the communication is secure.
00:03
Those certificates are granted
00:03
by a certificate authority.
00:03
Now, it used to be that back in the day,
00:03
SSL and TLS certificates used to cost a lot of money.
00:03
Now, there are companies out there who still pay
00:03
lots of money for
00:03
certificates from a certificate authority.
00:03
However, there is a bit of
00:03
a small movement of
00:03
getting free certificate in people's hands.
00:03
One of those companies is called Let's Encrypt.
00:03
They are actually giving
00:03
free certificates out to everybody.
00:03
Now, it used to be that if you
00:03
had HTTPS on your web page,
00:03
people generally thought that your web page
00:03
was a trusting good web page because,
00:03
hey, you're paying hundreds of dollars
00:03
for your certificate.
00:03
There's no way you're going to be a bad guy.
00:03
Those guys don't pay that money for
00:03
secure stuff, for a user.
00:03
Well, now this is coming back to bite people
00:03
in the butt, these free certificates.
00:03
If you see HTTPS, yes,
00:03
the page is secure,
00:03
so you can trust the communications.
00:03
However, you can't trust the page itself.
00:03
You may go to a page that says,
00:03
hey, give us your credit card information.
00:03
It may be HTTPS,
00:03
but that doesn't mean that that page
00:03
is a page that you should trust.
00:03
It just means that you're not going to be
00:03
>> hit by a man in
00:03
>> the middle attack or
00:03
people aren't going to be listening
00:03
to your communications.
00:03
HTTPS uses certificates from a certificate authority.
00:03
How it works is,
00:03
first, SSL certificates are exchanged.
00:03
Those certificates are identifying, hey,
00:03
I am who I say I am and you can trust me.
00:03
After that exchange happens
00:03
and both hosts trust each other,
00:03
then the encryption keys are exchanged.
00:03
That's when all the communications are encrypted.
00:03
That's how HTTPS works, in a nutshell.
00:03
HTTP and HTTPS both work off of the TCP protocol.
00:03
Now, there's two
00:03
different protocols that you're going to see.
00:03
TCP and UDP.
00:03
TCP is a connection-oriented communication,
00:03
whereas UDP is a connectionless oriented communication.
00:03
What does that mean?
00:03
Well, TCP does what's known as the three-way handshake.
00:03
Whenever you go to browse to a page,
00:03
you host one,
00:03
send a TCP SYN packet to host two.
00:03
Host two, receives that packet and
00:03
acknowledges by sending a SYN ACK packet
00:03
>> back to host one.
00:03
>> Saying, "Hey, I see your communication attempt.
00:03
I acknowledge that communication attempt."
00:03
Then host one sends an ACK packet
00:03
>> back to host two saying,
00:03
>> "Hey, thanks for responding."
00:03
Then a TCP connection has been established.
00:03
Now, from that point on,
00:03
that communication is used to ensure
00:03
that all packets are received via communication.
00:03
They do that with things like the sequence number,
00:03
which is used throughout the communication to
00:03
identify if a packet may have been dropped.
00:03
However, if you're using something like UDP,
00:03
that is a connectionless oriented communication.
00:03
What that means is, UDP just throws all the packets at
00:03
whoever's trying to receive them and it
00:03
does not care if there's any packet loss.
00:03
TCP is great for
00:03
browsing the web because you're
00:03
going to get all your packets.
00:03
UDP is great for streaming of media.
00:03
If we use TCP for streaming of media,
00:03
that would be slowed down substantially.
00:03
One or two packets dropped here or there
00:03
will not matter for streaming of media,
00:03
but it will matter for TCP.
00:03
Because if you're dropping packets for
00:03
TCP and you're trying to browse a web page,
00:03
then you're going to not
00:03
get content that you want from the web page.
00:03
Whereas UDP, you may get a little bit
00:03
of a downgrade and
00:03
>> the quality of your streaming service.
00:03
>> Which is better to use, HTTP or HTTPS?
00:03
Well, HTTPS is always better to use.
00:03
HTTPS prevents a man-in-the-middle attack,
00:03
and HTTPS prevents eavesdropping
00:03
from packet analysis tools on a network.
00:03
All that communication will be encrypted
00:03
and nobody can pick
00:03
off your form field data or things like
00:03
your credit card or sensitive information.
00:03
HTTPS is always better to use.
00:03
If a site has an option to use HTTPS, always use that.
00:03
If you have the ability to
00:03
use SSL certificates on your web application, do it.
00:03
It will only make your web application stronger.
00:03
What was covered? Well, I discussed what is HTTP.
00:03
I also discussed what is HTTPS.
00:03
I talked about what TCP is and
00:03
the three-way handshake and how that works.
00:03
Then I told you which one's better,
00:03
which is HTTPS.
00:03
Happy hacking everyone.
Up Next
Instructed By
Similar Content
