Lab 8 solutions.
Task 1
It still has a SQL injection problem. For example, we can let eid be ¡°x, 256)¡¯ OR 1=1 #¡±. Task 2
No. This program does not have a SQL injection problem. Whatever code included in eid and passwd is already changed to something else, most likely noncode, due to the hash() function in the PHP code. In this case, although there is still a channel between remote users and the database, the data in the channel is modified, making it difficult, if possible, for attackers to send code via this data channel.
Task 3
Yes. If we put ¡°x¡¯ OR 1=1 #¡± inside eid, there will be a syntax error, because we have commented out the AND operator in the statement. We just need to make sure add an logical operator at the end. We can let eid be ¡°x¡¯ OR 1=1 OR #¡± (not including the beginning and ending quotation marks). The resulting statement will be equivalent to the following:
SELECT * FROM employee WHERE eid= ¡¯x¡¯ OR 1=1 OR password=¡¯$password¡¯
Task 4
$sql = “UPDATE employee SET password=¡¯?¡¯ WHERE eid =¡¯?¡¯ and password=¡¯?¡¯”;
if ($stmt = $conn->prepare($sql)) {
$stmt->bind_param(“sss”, $newpwd, $eid, $oldpwd); $stmt->execute(); … }
Task 5
We can put an image tag in the malicious web page:
Check slide 12 in CSRF lecture slides
Task 6
Yes. Browsers know from which page a request is initiated, and to which website the request is going. Therefore, browsers know whether a request is a cross-site request or not.
Task 7
If browsers provide some information to help the web server to distinguish whether an HTTP request is cross-site or not, the server will know. However, if browsers do not provide that information, the server will not know. All what a server sees is a request coming from a user¡¯s browser; it does not know from where the request is initiated: from its own page or from other website¡¯s page.
Task 8.
A request coming from a server¡¯s own page is considered as trusted, while requests from other website¡¯s page are not (and should not be) considered as trusted. A sever needs to be able to tell the difference, so it can treat these two types of requests differently. Cross-site requests should not be given the same privilege as the same-site ones.
Task 9.
The main objective of this task is to observe the HTTP request sent out by the Elgg web client to the Elgg server. We will use the HTTP header Live which is an extension or add on in the Firefox browser. To observe the HTTP request, we will simply login into the website with tool open. We can see that there are a bunch of GET and POST requests made to the web server.
The requests correspond to the login. The response to the login sends a webpage which is the activity page of the website. The rest of the GET requests are getting the JavaScript¡¯s and images required to render the webpage. To further understand a HTTP request, we can click on any of the HTTP request to see what parameters are sent with each request. As shown below, the following were the parameters sent along with the POST request that is sent to authenticate the user and login in to the website.
Figure
The main options to pay attention are the cookie and the elgg values attached along every request. We can see that the Cookie with a key-value pair is attached by browser with every HTTP request. Furthermore, we can see that in the content section, along with the username and password that are
required for login there are two parameters attached namely elgg_token and elgg_ts. These are special values implemented by the elgg website as countermeasure for the CSRF attacks. Next week, for the first few tasks we will disable the countermeasure, so the server will not validate if the tokens are present in the HTTP request but with countermeasures on the server will check if the values are present and valid. These values are generated randomly and uniquely for every user and are embedded into the webpage sent in response. If these values are present, then the request is from the same site while its absence signifies that the request is a cross-site.