Module No:

COMP 7025

Module title:

Secure Programming

Assessment title :

Blog Site

Due date and time:

Friday 3^rd May 2024 at 1pm

Estimated total time to be spent on assignment: 

40 hours per student (excludes 112 hours for independent / directed study)

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 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

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 software development and also the security analysis. You will be given feedback on how well you are performing on these tasks.

Deliverable description and instructions

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.

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.

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.

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.

Weighting

out of 100%

Security Analysis-Preliminaries: 

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.

10%

Security Analysis-Issues Found

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.

20%

Security Analysis-Fixes:

Fix two of the security flaws. You will be marked in the quality of the fix.

10%

Security Analysis-Conclusion:

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 you have left unfixed and provide an estimate of the resources required to fix them.

5%

Software Development-Interim Demonstration

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 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.

4%

Software Development-Design:

Give your design, explaining why you believe this will produce software that is maintainable and secure, responsive and easy to use.

4%

Software Development-Functional Requirements

Implement requirements FR1-FR3, each of which has equal importance to the marks. The code should be commented on appropriately, be concise, and have appropriate naming. About concision, functions and header files should be used to reduce the amount of duplicated code.

3x3=9%

Software Development-Security Requirements:

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.

8x3=24%

Software Development-Audit:

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.

9%

Bonus Marks from Semester 1 session

Installing lubuntu, compiling Hello World and making the first upload to GitHub repository.

5%

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

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 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. Order now

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 create their blog posts. One user will be the administrator and they will have the ability to create new users and set passwords for them.

Conduct a detailed and critical analysis of existing software and utilise the results to produce secure modifications to treat, or mitigate, any vulnerabilities found. Our samples

Name

Requirement

FR1

A user can view and edit their 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.

Name

Requirement

SR1

Both kinds of users must be able to log in with the password they have chosen.

SR2

Both kinds of users must be able to log out and will be automatically logged out after a fixed period 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 tokens to understand how they work and then think carefully about how to solve the problem of replicating that behaviour in software.