Faculty of Technology, Design & Environment
Assessment cover
STUDENTS, PLEASE COPY THIS PAGE AND USE AS THE COVER PAGE FOR YOUR SUBMISSION
Module No: COMP 7025 Module title: Secure Programming
Assessment title : Blog Site
Due date and time: Friday 3rd May 2024 at 1pm
Estimated total time to be spent on assignment: 40 hours per student (excludes 112 hours for
independent / directed study)
LEARNING OUTCOMES
On successful completion of this module, students will be able to achieve the module following
learning outcomes (LOs): LO numbers and text copied and pasted from the module descriptor.
LO2 Have a thorough understanding of the main attack vectors, commonly used to attack software,
and be able to design and implement software that reduces the likelihood of those
vulnerabilities being exploitable.
LO3 Conduct a detailed and critical analysis of existing software and utilise the results to produce
secure modifications to treat, or mitigate, any vulnerabilities found.
LO4 Design and implement concurrent and distributed software which operates in hostile
environments.
LO5 Design and implement secure software that utilises the underlying security model of the OS
and hardware architecture.
Engineering Council AHEP4 LOs assessed (from S1 2022-23):
M1 Apply a comprehensive knowledge of mathematics, statistics, natural science and engineering
principles to the solution of complex problems. Much of the knowledge will be at the forefront
of the particular subject of study and informed by a critical awareness of new developments
School of Engineering, Computing & Mathematics
and the wider context of engineering
M2 Formulate and analyse complex problems to reach substantiated conclusions. This will involve
evaluating available data using first principles of mathematics, statistics, natural science and
engineering principles, and using engineering judgement to work with information that may be
uncertain or incomplete, discussing the limitations of the techniques employed
M3 Select and apply appropriate computational and analytical techniques to model complex
problems, discussing the limitations of the techniques employed
M4 Select and critically evaluate technical literature and other sources of information to solve
complex problems
M5 Design solutions for complex problems that evidence some originality and meet a combination
of societal, user, business and customer needs as appropriate. This will involve consideration
of applicable health & safety, diversity, inclusion, cultural, societal, environmental and
commercial matters, codes of practice and industry standards
Statement of Compliance
I hereby declare that the work submitted is my own and that the work I submit is fully in accordance with the
University regulations regarding assessments ([Link]/uniregulations/current)
School of Engineering, Computing & Mathematics
FORMATIVE FEEDBACK OPPORTUNITIES
In the Week 8 practical session you will demonstrate that you are making progress on the software
development so that advice can be given if you are not; the work must be uploaded to the repository
before the practical session. Advice will also be available in the module leader’s office hours and at the
end of the practicals for each week. The practicals contain exercises that focus on aspects of the
software development and also the security analysis. You will be given feedback on how well you are
performing on these tasks.
SUMMATIVE FEEDBACK DELIVERABLES
Deliverable description and instructions Weighting
out of 100%
Upload your report to Moodle (Turnitin link) with the coversheet provided before the due
date. Your report should contain all of your code for both the security analysis (i.e. the
original code as modified by you) and the software development. All of your code should
be in an appendix to your report in addition to any code extracts quoted in the report.
Code should be pasted; screengrabs containing code must not be used and will not be
marked.
The code for the software development must be uploaded to a GitHub repository that will
be given to you. You will demonstrate that this code meets the functional requirements in
the Week 12 practical session. You will also do an interim demonstration in the Week 8
practical session.
Security Analysis-Preliminaries: 10%
Reverse engineer documentation for the source code. Comment it clearly with all the
assumptions it makes about program inputs and other variables, including full
documentation of each function including assumptions made about parameters.
Security Analysis-Issues Found 20%
Explain four security flaws that you have found and their implications. You will be marked
on your understanding of the code and the potential attack vectors against secure
software.
Security Analysis-Fixes: 10%
Fix two of the security flaws. You will be marked in the quality of the fix.
Security Analysis-Conclusion: 5%
Summarise the issues found, run the modified program through a static analyser like
splint and reflect on what you have seen. Discuss the implications of not fix the two flaws
School of Engineering, Computing & Mathematics
you have left unfixed and provide an estimate of the resources required to fix them.
Software Development-Interim Demonstration 4%
This is an early assessment in the Week 8 practical designed to make sure that you can
work with the software needed to complete this coursework.
The task is to write and run a program that extracts the contents of an SQL table and
prints it as an attractively formatted HTML table. You will also need to explain how you
did it, show your database design (which should be completed by that point) and explain
your future plans for implementing the rest of the requirements, giving details of both the
static and the dynamically-created web pages and of the cpp files that compile into
programs that create the latter.
Software Development-Design: 4%
Give your design, explaining why you believe this will produce software that is
maintainable and secure, responsive and easy to use.
Software Development-Functional Requirements 3x3=9%
Implement requirements FR1-FR3, each of which has equal importance to the marks.
The code should be commented appropriately, be concise, and have appropriate naming.
With regard to concision, functions and header files should be used to reduce the amount
of duplicated code.
Software Development-Security Requirements: 8x3=24%
Implement requirements SR1-SR8, each of which has equal importance to the marks.
The code should be commented appropriately, be concise, and have appropriate naming.
Software Development-Audit: 9%
Demonstrate that all of the security requirements have been met and, related to this,
explain how you would approach the website from the perspective of an attacker. You will
be marked, respectively, according to rigour of your testing of these security
requirements and the evidence you have learned more than is just in the lectures. You
should also reflect on what you have learned and what you would do differently next time.
Bonus Marks from Semester 1 session 5%
Installing lubuntu, compiling Hello World and making first upload to GitHub repository.
Marking grid and peer marking form are attached at the end of this assignment.
ASSIGNMENT IN DETAIL: OUTLINE
The coursework is in two parts:
1. A security analysis, to see whether you can discover and fix security flaws in other
people’s code
2. A software development, requiring you to build secure software from scratch
School of Engineering, Computing & Mathematics
SECURITY ANALYSIS
You have been given a program, consisting of three files prog.c, utils.c and utils.h, with several security
flaws. You can compile and run the code on the VM that you have been given but you will need to
examine the source code itself (which the attacker has access to) and think carefully about how it works,
including any assumptions that are made about inputs. You have to identify four security flaws and fix
two of them. The commands to compile and run the files are:
gcc -o prog.o prog.c utils.c
./prog.o
The program is intended to store for every user a blog post which can be uprated or downrated by the
other users. The blog posts are stored in text files which the user does not have direct access to. A
separate user called admin (short for administrator) has the power to create new users, set the password
for the new user and give them a blank blog post to edit.
Note that we are looking for security issues, rather than bugs or usability flaws. It’s up to you to decide
which ones you want to fix, according to how well you feel you can fix them.
SOFTWARE DEVELOPMENT
The software you are writing is a CGI program written in C++. This means that it is running on a web
server and it will be accessed through a web interface. You have been given a virtual machine with
software that you need pre-installed together with all the necessary libraries including CGICC. You may
use alternatives to CGICC if you wish but you must check with the module leader first. In any case, you
must use C++ and submissions not using C++ will not be marked. Similarly, you have been given the
MariaDB Connector library and may only use alternatives to it if you have the module leader’s
permission.
The function of the software is a blog post management system. Users will use it to view blog posts, rate
blog posts up and down and to create their own blog posts. One user will be the administrator and they
will have the ability to create new users and set passwords for them.
FUNCTIONAL REQUIREMENTS FOR SOFTWARE DEVELOPMENT
Name Requirement
FR1 A user can view and edit their own blog posts.
FR2 A user can view the blog posts of other users and uprate or downrate them.
FR3 The administrator can create new user accounts and set passwords and email
addresses for them.
SECURITY REQUIREMENTS FOR SOFTWARE DEVELOPMENT
School of Engineering, Computing & Mathematics
Name Requirement
SR1 Both kinds of user must be able to log in with the password they have chosen.
SR2 Both kinds of user must be able to log out and will be automatically logged out after
a fixed period of time of inactivity.
SR3 The software must maintain a session and it should do so using cookies.
SR4 If a user attempts to access a page without being logged in, they should be
redirected to the log in page.
SR5 Passwords must be encrypted when stored in the database; you may use
cryptographic libraries for this if you wish.
SR6 All user inputs should be sanitised before they are used.
SR7 The process of logging in should use two-factor authentication. The user must enter
a second password sent by email after the main password has been entered. The
email address to be used is the one entered when registering the account. If you
are not able to install the relevant mail library, you can simulate the process of
emailing by appending to a “mail spool” text file representing all the emails that
have been sent.
SR8 The administrator account, in addition to the protections of SR7, must be
authenticated by a challenge-response software that simulates the concept of a
hardware token. You are encouraged to do the necessary research into the concept
of hardware token to understand how they work and then think carefully about how
to solve the problem of replicating that behaviour in software.
This is an individual piece of work and you will have to work on your own and submit your own original
attempt at the assignment. Any code that has been copied from any source (e.g. Stack Overflow, online
tutorial, textbooks, other students etc.) must be properly referenced to avoid any suspicion of plagiarism. If
you need help you can always ask for advice and guidance from the module leader by email; online
sessions can be arranged for further clarification.
School of Engineering, Computing & Mathematics
Oxford Brookes University
Your security analysis will be marked according to the following rubric.
Fail Pass Distinction Ideal
Prelim Source code commenting of Source code commented Fairly well commented source code Clearly commented source code with
only obvious statements or but only in some places or but few statements about values of meaningful assumptions about inputs and
some statements only obvious statements input and other variables or lines other variables as required, including full
commented inaccurately commented and little about mechanically commented without documentation of each function
values of variables or much understanding of how they fit
parameters together or function parameters or
purposes incompletely specified
Issues attack vector description is vaguely correct description attack vector well understood in attack vector extremely understood in
rather vague or is incorrect of attack vector but it is not reasonable detail for a relevant reasonable detail for a relevant attack and is
or it is not a security issue clear why it is a security attack communicated persuasively with technical
issue detail
Fixes vague or inadequate design good design and good design and explanation and good code quality, design, rigorous
and explanation and no explanation but very little implementation but missing testing explanation and testing
actual implementation of actual implementation or
testing testing
Conc Poor knowledge of the Adequate knowledge of the Good knowledge of the principles Excellent knowledge of the principles of
principles of secure design principles of secure design of secure design when discussing secure design when discussing splint
when discussing splint when discussing splint splint results, fixed vulnerabilities, results, fixed vulnerabilities, and
results, fixed vulnerabilities, results, fixed vulnerabilities, and vulnerabilities not yet fixed with vulnerabilities not yet fixed synthesising new
and vulnerabilities not yet and vulnerabilities not yet a hint of new ideas ideas in the manner expected at this level
fixed fixed
Your software development will be marked according to the following rubric.
Oxford Brookes University
Fail Pass Distinction Ideal
Interim Task less than half Task half-completed Task completed and explained Task completed and satisfactorily explained
completed with excellent plan for further development
Design Covered inadequately in the Lacking in necessary detail Explained persuasively or well- Explained persuasively and well-
report or is very flawed or has major flaws or there documented but not both documented
is little attempt to answer
the question posed
Fun Reqs Only some functionality Only some functionality All functionality fully implemented All functionality fully implemented to the
implemented and not to the implemented or the to the specified code quality specified code quality standards
specified code quality implementation is not to the standards with very minor flaws
standards specified code quality
standards
Sec Reqs Half-implemented and Half-implemented or Implemented in a manner that Implemented to the specified code quality
implemented in a manner implemented in a manner satisfies the security goal but not to standards in a manner that satisfies the
that does not satisfy the that does not satisfy the the specified code quality security goal
security goals security goals standards
Audit Poor knowledge of the Adequate knowledge of the Good knowledge of the principles Excellent knowledge of the principles of
principles of secure principles of secure of secure software design with a secure software design synthesising new
software design software design hint of new ideas ideas in the manner expected at this level
Bonus Some tasks completed by All tasks completed by first Almost all tasks completed by the All tasks completed by the end of semester
Marks first lecture of semester 2 lecture of semester 2 end of semester 1 1
Oxford Brookes University
