Summary - Cyberattacks Crime and Defenses
Lecture 1 - Webapps and Attack principles
Web applications
Until a few years ago attacks used to be on operating systems
➔ Now it is easier to attack the (web) applications
• A direct attack (E.g., steal information)
• Or, indirect attack (E.g., attack a user using the web application)
Visiting a website
Your browser (Internet Explorer, Firefox, Safari, Opera) will display:
• Content from the website itself
• Content coming from external sites (tens or sometimes hundreds)
o The website will also transmit some information to these websites sometimes.
• Aggregate content from a number of advertisers
This means that:
• The visited website carries out operations
• The external sites may carry our operations
• The input (E.g., IP address, cookies, etc.) to the operations is partly determined by
them (external sites / advertisers)
This is what it looks like:
• Each box is a software component and it
has its own vulnerabilities.
• The third party content is particularly
untrusted.
TamperData / TamperChrome can be used to
have a look at all the HTTP requests when one
visits a website:
• In most cases the password is sent in the
clear, this can be intercepted. Unless,
HTTPS is used.
• Notice, that you are able to modify the
parameters.
TamperData works by intercepting and inspecting network traffic at the browser level. POST parameters may not be
visible in the URL, but they are still transmitted in the HTTP request body, which tools like Tamper Data can easily
capture. This is why POST should never be assumed to "secure" data—it only avoids visibility in URLs, and proper
encryption (via HTTPS) is essential for true security.
,Parameters of a HTTP request
The usual ones:
• Host
• Referer: The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header
field that identifies the address of the webpage (i.e. the URI or IRI) that linked to the
resource being requested.
➔ By checking the referrer, the new webpage can see where the request originated
• Cookies
The unusual ones:
• Referee: The last place you visited before you visited this specific site (sent through
next site via HTTP request) ➔ This is very privacy sensitive
• Username
• Password
GET and POST parameters
When you fill in a parameter inside a search bar and it gets added to the URL, then it is a
GET parameter. If not, it is a POST parameter.
➔ When you fill in your username and password on Facebook, these get send to the server
in some way namely via POST parameters. (To see them you’d ned to use a tool like
TamperData)
Difference in usage: GET vs. POST parameter
GET parameters used for input fields:
• HISTORY: Parameters remain in browser history.
o This means you can bookmark a GET parameter: saving URL that includes
query parameters as a bookmark in your browser. (allows to quickly return to
specific state)
• SECURITY: GET is less secure, data is sent as part of the URL:
o When using GET parameters, the filled in input fields are visible in the URL
and hence way less secure.
The same thing happens happens when you click on one of the buttons.
o An attacker can manually create or manipulate the GET parameters, including
adding harmful parameters to the link your victim has to click on. This then
triggers actions without the victim knowing.
➔ Example: https://example.com/deleteAccount?userId=456
POST parameters used for input fields:
• HISTORY: Parameters are not saved in browser history.
• SECURITY: POST is a little safer than GET
o The parameters are not stored in browser history or in web server logs. They
are “hidden” in the request: not visible in the URL
o Still visible in the HTTP request body when one captures this network traffic.
o Not safe either: for that one needs encryption (e.g.: HTTPS).
,HTTP response
The response contains interesting information:
• The status of the request (status: OK - 200)
• Parameters that may be reused
Some parameters are encoded
• This is to make the request more digestible by the webserver, web application
• Very often the web application accepts several different encodings
o Hexadecimal encoding: 0x41 = A, etc.
o URL encodings: %3d =, %0a new line, etc.
One of the underlying problems: HTTP “weak” sessions
HTTP is connectionless
• It is sessionless, and does not have a “state”: this means that when a client talks to
the server; the web application does not know who or where this request came
from, it has no memory of what you have done so far.
o Small exception: HTTP keep-alive, or HTTP connection reuse in which you
reuse the same TCP connection (Connection: Keep-alive), this is however
often unlinked to the application logic, so as far as we are concerned there is
no connection state.
• How do we then handle stateful requests (think of
adding an item to a cart in an online shop and
knowing this is done by client 44)?
➔ By storing a cookie on the client and let
the client send this cookie when sending a
request. When obtaining the cookie, the
server obtains the stored session. So,
information (who are you / what have you
done so far) about the session is stored in
your browser.
Why don’t we use SSL to “solve” these problems?
➔ SSL does not help against the attacks we just
mentioned!
• SSL takes care of securing the communication
(TCP/IP) between client and server, but it does not
armor the client’s browser!
• E.g., it helps against eavesdropping if you are at an internet café.
➔ So, SSL is a solution for a different problem!
, Other possible injection:
…… UNION SELECT * FROM users WHERE ….
SQL Injection
The web application presents a form with
username and password which in the SQL
database gets handled as follows (see
image).
What happens if we give the following input:
• Username: just any legal user name
• Password: anything’ OR ‘x’=’x
Then the MySQL command becomes:
SELECT … FROM users WHERE username
= ‘luke’ AND password = ‘anything’ OR ‘x’=‘x’ (it does not matter what you type for “anything”)
➔ Then, it gets parsed the wrong way.
➔ The above query selects all users with the username ‘luke’, so the reply is the list of all
users, together with all the parameters that are in the list.
What is SQL?
➔ A language used by databases to specify queries
• Data is stored in Tables, and each table has a name and a number of fields (or
columns)
• Each Table contains a number of records or rows (inputs)
• To access the data in these rows, we use queries
What is an SQL injection?
• Web applications use SQL databases to store information, SQL is then interpreted by
MySQL/Oracle/etc. Which can read, update, add and delete database information.
• User-supplied information is passed from client (browser) to web application via e.g.
GET, POST and COOKIE parameters.
➔ SQL Injection: Crafting user-supplied input so to execute database queries beneficial to
the attacker’s project, e.g.: retrieve the user accounts and credentials to obtain unauthorized
access.
• Still a widespread bug.
Command injection
An SQL injection is just one type of “command injection” (the most common one).
• Depending on the underlying DB, you could inject other kind of commands.
(Same principles, only practice is different)
➔ In general: The purpose of a command injection attack is to inject and execute
commands specified by the attacker in a vulnerable application
• Attacker exploits the fact that developers trust users too much and usually don’t know
how to program.
• Injection does not only affect web applications. (E.g.: (RFID) Radio Frequency
Identification systems can be exploited as well to inject malicious code or alter data.)
Lecture 1 - Webapps and Attack principles
Web applications
Until a few years ago attacks used to be on operating systems
➔ Now it is easier to attack the (web) applications
• A direct attack (E.g., steal information)
• Or, indirect attack (E.g., attack a user using the web application)
Visiting a website
Your browser (Internet Explorer, Firefox, Safari, Opera) will display:
• Content from the website itself
• Content coming from external sites (tens or sometimes hundreds)
o The website will also transmit some information to these websites sometimes.
• Aggregate content from a number of advertisers
This means that:
• The visited website carries out operations
• The external sites may carry our operations
• The input (E.g., IP address, cookies, etc.) to the operations is partly determined by
them (external sites / advertisers)
This is what it looks like:
• Each box is a software component and it
has its own vulnerabilities.
• The third party content is particularly
untrusted.
TamperData / TamperChrome can be used to
have a look at all the HTTP requests when one
visits a website:
• In most cases the password is sent in the
clear, this can be intercepted. Unless,
HTTPS is used.
• Notice, that you are able to modify the
parameters.
TamperData works by intercepting and inspecting network traffic at the browser level. POST parameters may not be
visible in the URL, but they are still transmitted in the HTTP request body, which tools like Tamper Data can easily
capture. This is why POST should never be assumed to "secure" data—it only avoids visibility in URLs, and proper
encryption (via HTTPS) is essential for true security.
,Parameters of a HTTP request
The usual ones:
• Host
• Referer: The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header
field that identifies the address of the webpage (i.e. the URI or IRI) that linked to the
resource being requested.
➔ By checking the referrer, the new webpage can see where the request originated
• Cookies
The unusual ones:
• Referee: The last place you visited before you visited this specific site (sent through
next site via HTTP request) ➔ This is very privacy sensitive
• Username
• Password
GET and POST parameters
When you fill in a parameter inside a search bar and it gets added to the URL, then it is a
GET parameter. If not, it is a POST parameter.
➔ When you fill in your username and password on Facebook, these get send to the server
in some way namely via POST parameters. (To see them you’d ned to use a tool like
TamperData)
Difference in usage: GET vs. POST parameter
GET parameters used for input fields:
• HISTORY: Parameters remain in browser history.
o This means you can bookmark a GET parameter: saving URL that includes
query parameters as a bookmark in your browser. (allows to quickly return to
specific state)
• SECURITY: GET is less secure, data is sent as part of the URL:
o When using GET parameters, the filled in input fields are visible in the URL
and hence way less secure.
The same thing happens happens when you click on one of the buttons.
o An attacker can manually create or manipulate the GET parameters, including
adding harmful parameters to the link your victim has to click on. This then
triggers actions without the victim knowing.
➔ Example: https://example.com/deleteAccount?userId=456
POST parameters used for input fields:
• HISTORY: Parameters are not saved in browser history.
• SECURITY: POST is a little safer than GET
o The parameters are not stored in browser history or in web server logs. They
are “hidden” in the request: not visible in the URL
o Still visible in the HTTP request body when one captures this network traffic.
o Not safe either: for that one needs encryption (e.g.: HTTPS).
,HTTP response
The response contains interesting information:
• The status of the request (status: OK - 200)
• Parameters that may be reused
Some parameters are encoded
• This is to make the request more digestible by the webserver, web application
• Very often the web application accepts several different encodings
o Hexadecimal encoding: 0x41 = A, etc.
o URL encodings: %3d =, %0a new line, etc.
One of the underlying problems: HTTP “weak” sessions
HTTP is connectionless
• It is sessionless, and does not have a “state”: this means that when a client talks to
the server; the web application does not know who or where this request came
from, it has no memory of what you have done so far.
o Small exception: HTTP keep-alive, or HTTP connection reuse in which you
reuse the same TCP connection (Connection: Keep-alive), this is however
often unlinked to the application logic, so as far as we are concerned there is
no connection state.
• How do we then handle stateful requests (think of
adding an item to a cart in an online shop and
knowing this is done by client 44)?
➔ By storing a cookie on the client and let
the client send this cookie when sending a
request. When obtaining the cookie, the
server obtains the stored session. So,
information (who are you / what have you
done so far) about the session is stored in
your browser.
Why don’t we use SSL to “solve” these problems?
➔ SSL does not help against the attacks we just
mentioned!
• SSL takes care of securing the communication
(TCP/IP) between client and server, but it does not
armor the client’s browser!
• E.g., it helps against eavesdropping if you are at an internet café.
➔ So, SSL is a solution for a different problem!
, Other possible injection:
…… UNION SELECT * FROM users WHERE ….
SQL Injection
The web application presents a form with
username and password which in the SQL
database gets handled as follows (see
image).
What happens if we give the following input:
• Username: just any legal user name
• Password: anything’ OR ‘x’=’x
Then the MySQL command becomes:
SELECT … FROM users WHERE username
= ‘luke’ AND password = ‘anything’ OR ‘x’=‘x’ (it does not matter what you type for “anything”)
➔ Then, it gets parsed the wrong way.
➔ The above query selects all users with the username ‘luke’, so the reply is the list of all
users, together with all the parameters that are in the list.
What is SQL?
➔ A language used by databases to specify queries
• Data is stored in Tables, and each table has a name and a number of fields (or
columns)
• Each Table contains a number of records or rows (inputs)
• To access the data in these rows, we use queries
What is an SQL injection?
• Web applications use SQL databases to store information, SQL is then interpreted by
MySQL/Oracle/etc. Which can read, update, add and delete database information.
• User-supplied information is passed from client (browser) to web application via e.g.
GET, POST and COOKIE parameters.
➔ SQL Injection: Crafting user-supplied input so to execute database queries beneficial to
the attacker’s project, e.g.: retrieve the user accounts and credentials to obtain unauthorized
access.
• Still a widespread bug.
Command injection
An SQL injection is just one type of “command injection” (the most common one).
• Depending on the underlying DB, you could inject other kind of commands.
(Same principles, only practice is different)
➔ In general: The purpose of a command injection attack is to inject and execute
commands specified by the attacker in a vulnerable application
• Attacker exploits the fact that developers trust users too much and usually don’t know
how to program.
• Injection does not only affect web applications. (E.g.: (RFID) Radio Frequency
Identification systems can be exploited as well to inject malicious code or alter data.)
