Assessment Brief
Module number SET10113
Module title Secure Software Development
Module leader Dr Zakwan Jaroucheh
Tutor with responsibility for
this Assessment
Dr Zakwan Jaroucheh
Assessment Practical Assessment
Weighting 60% of module assessment
Size for assessment Approx 20 hours for the first part and approx 15
hours for the second part.
Deadline of submission
Your attention is drawn to the penalties for late
submissions
Demonstration submission (video to be uploaded):
Fri 10th Apr by 15:00
Report submission: Fri 10th Apr by 15:00
Arrangements for
submission
This coursework is assessed in two parts, a hands-on
part (with Demonstration and code submission) and
a critical report. You are advised to keep your own
copy of the assessment.
Assessment
Regulations
All assessments are subject to the University
Regulations.
The requirements
for the assessment
This coursework is based on the taught academic
content of the module (all LOs). Students are
required to identify specific security vulnerability,
assess their risk, and fix them. Also, they are required
to write an essay about one topic related to the
software security. See attached specification.
Return of work and feedback Marks and feedback will normally be communicated
via Moodle within 3 weeks of submission.
Assessment criteria The code and report will be marked against the
criteria laid out in the respective Marking Schedule.
Note that there are no extra marks to be gained by
the code submission, but it is required to ensure
integrity.
SET10113 – Secure Software Development
Coursework – Part 1
In this coursework, you will make an assessment of a Web application from a
security perspective. This includes discovering specific types of vulnerabilities,
assessing their associated risk, and fixing them. You will need to implement a
simple detection mechanism to report and prevent malicious attacks. In addition,
you will need to do some research about one topic related to the software security.
Scenario – Vulnerable Web Application
You are a software engineer participating in developing a Web application called
NapierUniPortal. Your development team is under pressure to deliver the MVP
(minimum viable product) of the system before the deadline, and to demo that
system to the management. Therefore, the focus is on delivering the required
features rather than on addressing the security concerns. Now that the MVP has
been built, you have been assigned the task to review the NapierUniPortal from
the security perspective and work with the team to address the discovered
security issues.
You need to report to your manager. Things that are expected to be covered are:
Access control
Vulnerabilities analysis, risk assessment and vulnerability fixing (including
XSS, CSFR and SQL Injection vulnerabilities)
Attack detection mechanism
Note that the NapierUniPortal project will be available as part of the same VM
image used in the labs, in the folder /home/student/Secure-Software-
Development-Module-Coursework/NapierUniPortal
The NapierUniPortal Application
The application is used to manage students and their courses’ enrolments. Fig. 1
illustrates the meta-model. The non-admin users should be able to register and
login to the application. The admin users should be able to manage the users
(students) and assign enrolments/courses to them. The implemented access
control mechanism is expected to restrict access to the system features according
to Table 1.
Fig. 1. MetaModel
Table 1. Access control
Coursework – Part 1, Tasks
For this part of the coursework, you are required to do the following tasks:
1. Fixing the access control implementation
As you may notice, the student user is able to create or edit course programs, and
the see other users’ enrolments.
You need to choose an access control strategy and implement an access control
mechanism to restrict the systems features according the above table.
2. Identifying and fixing XSS vulnerability(ies)
- You need to conduct a manual code review and/or run some static analysis tool
to determine if the application is vulnerable to XSS attack.
- You need to assess the risk associated with the vulnerability(ies), score it, and
translate that finding into a language understood by the project manager.
- You need to fix the vulnerability, and explain your approach (e.g. from the client
side, from the server side, or from both side and why).
Non-Admin Admin
Add/edit/delete courses
Add/edit/delete enrolments
Add/edit/delete programs
View courses
View programs
View enrolments Only the current user enrolments
3. Identifying and fixing CSRF vulnerability(ies)
As part of the code review process, you need to ensure that the system sends a
CSRF token along with any form. Describe the issue in implementing the CSRF
prevention mechanism in the Web page that allows admin users to change users’
roles, and explain your recommendation to fix that issue.
4. Identifying the linkage between vulnerabilities
Let’s assume that you have identified the two potential vulnerabilities above:
Explain what is the linkage between them (if any), how this linkage could be
leveraged by an attacker, and what are the possible consequences.
5. Identifying and fixing SQL Injection Vulnerability(ies)
- You need to conduct a manual code review and/or run some static/dynamic
analysis tool to determine if the application is vulnerable to SQL Injection attack.
- You need to assess the risk associated with the vulnerability(ies), score it, and
translate that finding into a language understood by the project manager.
- You need to fix the vulnerability(ies), and explain your approach.
6. Implementing an attack detection mechanism
At this point, you may start to realise that there might be more undiscovered
vulnerabilities, we don’t enough time to fix every single vulnerability, and our
defences may not be perfect. Given enough time, attackers can identify security
flaws in the design or implementation of an application. Therefore, your task is to
implement a detection mechanism in the Web application to identify malicious
individuals before they are able to identify any gaps in our defences.
In order to limit the scope, let’s focus on detecting the SQL injection attacks. One
possible way to implement the detection mechanism is by using the OWASP
AppSensor Framework.
7. Providing your thoughts
Your team has successfully demoed the Web application, and it is the time now for
the retrospective meeting. As part of your preparation for that meeting, you need
to elaborate on the following points:
What went well and why?
What went wrong and why?
How the development process could be improved and how it should be
planned in the future.
Coursework – Part 2
In this part, you need to choose one of the following topics:
1. Lessons learned from well-known vulnerabilities
The aim of this part is to create in your own words a detailed description of one of
the widely known vulnerabilities including the vulnerability analysis, the
exploitation probability and the lessons learned from the mistakes caused these
vulnerabilities. You can choose one of the following vulnerabilities:
CVE-2014-3566 - Poodle
CVE-2014-0160 - Heartbleed
CVE-2017-5638 (Equifax breach)
Example of the points that could be covered in your report:
What is the vulnerability, what are the affected systems, and what impact it can
cause?
What is the root cause?
What is the associated risk and its score?
How the vulnerability can be exploited?
What are the lessons that could be learned from this vulnerability? Describe
your recommendations in terms of the SDLC practices to avoid this type of
vulnerabilities in the future.
2. Secure SDLC Methodology
Many methodologies have been proposed and implemented that are currently
helping organizations integrate security within their SDLC. Here are some
examples of these methodologies:
OpenSAMM
BSIMM
Microsoft SDL
Your task is to choose one of the methodologies, explain it in your own words, and
provide your thoughts about it. Things that are expected to be covered are (this is just
a non-exhaustive list of guidelines):
- Detailed description of the methodology.
- The promises of this methodology such as the cost savings brought about by
the early integration of security within the SDLC, avoiding the costly design
flaws, and increasing the long-term viability of software projects.
- Its applicability/suitability for the agile development methodology.
- Its implementation cost/difficulty.
- The main limitations/drawbacks of that methodology.
Coursework Submission
1. Look at the marking schedule detailing the evaluation criteria. Ensure you
are meeting them, within the context of the scenario.
2. You will be required to demonstrate your work on Wed 25th Mar at
11:00 in C27 and Thu 26th Mar at 09:00 in C27 (at your normal
practical slot in Week 12).
3. You need to submit the following deliverables by the deadline (Fri 10th Apr
by 15:00):
a. Report: Please submit a pdf version of your report. Do not submit Word
or TEX files. The name of the pdf file should be your student number. The
essay of Part 2 should be no more than 1000 words long (excluding
references). The essay part will not be marked if the number of words
exceed 1000 words.
b. Code: Please submit one zip file containing all the files that you have
changed. No need to submit the whole project along with its libraries. The
zip file should be named with your matriculation number.
Coursework, Part 1 – Marking schedule
No Item Mark
1 Access Control
- Description of the access control strategy and its implementation 3
2 XSS Vulnerability(ies)
- How the vulnerability has been found (e.g. tools/manual review) 2
- Description of the associated risk, the score, and the reporting 3
- Vulnerability fixing 4
3 CSRF Vulnerability
- Identification of the issue and its associated risk in the CSRF
implementation
2
- Evidence of potential CSRF vulnerability (e.g. implementing a
vulnerability exploitation script)
3
- Your recommendation for fixing the vulnerability 4
4 Linkage between the XSS and CSRF vulnerabilities
- Explanation of the linkage and this could be leverage by an
attacker
3
5 SQL Injection Vulnerability(ies)
- Identification of the SQL Injection vulnerability(ies) 2
- Description of the associated risk, and the reporting 3
6 - Vulnerability fixing 4
7 Attack Detection
- Description of the events and the detection points that we need to
focus on.
1
- Implementing an attack detection mechanism 3
8 Retrospective thoughts
- What went well 1
- What went wrong 1
- Your recommendations 1
9 Demonstration 10
Total 50
Marker’s Notes
............................................................................................................................. ...........................................
........................................................................................................................................................................
............................................................................................................................. ...........................................
Coursework, Part 2 – Marking schedule
No Item Mark
1 Lessons learned from well-known vulnerabilities
- The vulnerability description and its root cause 10
- The associated risk 5
- How the vulnerability can be exploited 5
- What are the lessons that could be learned from this vulnerability
Security mind-set: Ability to analyse and draw lessons from vulnerabilities already found in
other systems.
20
- Quality of written report
Quality of written English, quality of any displayed diagrams, document flow (i.e. does your
work read like several sections which have little in common, or like a coherent narrative?)
5
- Extension
In what ways have you extended the discussion of the given topic? This part of the mark
scheme is intentionally under-specified.
5
2 Secure SDLC Methodology
- The methodology description 10
- The promises of the methodology 10
- Its applicability/suitability for the agile methodology 5
- Its implementation cost/difficulty. 5
- The main limitations/drawbacks of the methodology 10
- Quality of written report
Quality of written English, quality of any displayed diagrams, document flow (i.e. does your
work read like several sections which have little in common, or like a coherent narrative?)
5
- Extension
In what ways have you extended the discussion of the given topic? This part of the mark
scheme is intentionally under-specified.
5
Total 50
Marker’s Notes
............................................................................................................................. ...........................................
........................................................................................................................................................................
............................................................................................................................. ...........................................