Unit 4

Learning Outcomes Achieved

1. Identify & manage security risks as part of a software development project
2. Critically analyse development problems and determine appropriate methodologies, tools and techniques to solve them

Seminar 2 Preparation

Towers of Hanoi

Working on the Towers of Hanoi problem helped improve my problem solving because I learned the value of “intuition” when it comes to algorithm creation, along with having concrete steps (and backup plans) for solving a problem. For this example, I challenged myself to try and understand the algorithm within a few hours, which forced me to try new ways of problem solving because I usually take my time to learn an algorithm. My first attempt at understanding the algorithm was to write a program that would solve a 3-disk version of the problem step by step, and then convert similar groups of code into helper methods, eventually turning it into a general solution. This approach was not successful because different disk numbers would cause different movements to happen, so it would not be possible to use groups of similar procedures to solve the problem. In light of this, I changed my strategy to finding common patterns across variants of the problem. To do this, I worked on finding solutions which required the lowest number of moves, for towers of size 3, 4, and 5. After finding the optimal moves and working through each variant step-by-step, I noticed that all optimal solutions, at some point, would cause n-1 disks to appear on the second rod (where n is the total amount of disks). Discovering this pattern through trial-and-error made it easier for me to understand the recursive solution. This problem-solving process is something that I can use for any situation where I need to create an algorithm from scratch.

I gained other insights which could be used in my work, and in my studies. During my research related to recursion, I came across the concept of a zip bomb- a zip file structured in such a way that, when extracted, would cause a computer to run out of memory or disk space (Fifield, 2019), effectively causing a denial-of-service if done on an appropriate machine. The interesting part of this file is that it exploits recursive zip file extraction, although it can also do so non-recursively. This highlights the risks involved in using recursion- stack overflow errors can easily be triggered by an attacker. It is possible to write recursive code that does not result in a stack overflow in python (Penner, 2016), but this does not eliminate the possibility of a denial-of-service, it merely allows a recursive function to run more times than it should. As a result, no recursive functions will be used in the development of the application.

This exercise helped me achieve learning outcome 1, becuase I was able to identify a new threat to an application, and take steps to prevent it from becoming an attack vector.

UK Postcode Regex

The topic of regex, and regex security, was interesting to learn about because there is a certain level of ambiguity when it comes to classifying evil regex patterns. There are no widespread regex checkers which check the efficiency of a given pattern- something that would benefit any developer that uses regex. This means that a developer would have to rely on theoretical knowledge and general principles in order to determine if a regex pattern is evil or not, even though regex is an ideal use case for static code analysis. Based on the lack of widespread/commonly used regex checkers, I argue that most developers are therefore unaware of the vulnerabilities contained within regex patterns and this lack of awareness is exacerbated by the lack of standardization/best practices around regex itself. I discovered regexploit as a result of my research (Caller, 2021), and it would be ideal to use in the module assignment because it can be used to guarantee the safety of regex patterns used for certain inputs (such as emails).

This exercise helped me achieve learning outcome 1, because I identified a threat to the application which my team needs to develop, and found a way of eliminating this threat.

Seminar 2 Preparation Artefacts

Link to Jupyter Notebook

Seminar 2

An interesting discussion was held during the seminar, regarding the concept of a “safe” language and how language concepts (such as abstraction and encapsulation) can affect that. Andrey discussed how encapsulation and polymorphism could arguably improve the security of a system, and in comparison, how Python could be argued to be “less safe” due to its lack of reliance on private properties and methods due to dynamic typing and duck-typing. I agree with this argument: although writing “safe” Python is theoretically possible, it would rely on a developer intentionally avoiding code that they should not access- nothing in Python is truly private (Python Software Foundation, 2021). Safe code in Python would also require more cognitive effort- the lack of a compiler means that the developer needs to manually assess code for logical consistency and safety.

This discussion reminded me of the Rust programming language, and its emerging role in the software engineering field. Microsoft notes that approximately 70% of security vulnerabilities across all their products are related to memory bugs (Cimpanu, 2019). Rust is currently promoted as a language of the future because it guarantees memory safety without the need for a runtime- resulting in lightweight applications which can be optimized at a low-level for various CPU architectures. Simply switching to Rust would therefore eliminate any risk of a memory vulnerability from occurring- although this comes with the learning curve of understanding Rust’s memory model (i.e. ownership and borrowing).

In light of the arguments made above, I would argue that convenience and ease of use should be considered when developing secure software. Being able to place cognitive load onto programming languages via compilers, makes it easier to develop secure software, because the compiler forces a developer to write compliant code. While it is possible to write safe code in a language like Python (assuming the developer is sufficiently skilled), the code written by a developer in a language like that cannot be guaranteed to be consistent- no compiler means no automated checks, and no automated checks means that forgetfulness is permissible. Code reviews and other forms of analysis (such as static analysis) can mitigate this risk, if a dynamically-typed and non-encapsulated language must be used. As a result, during the coding for the assignment due in Unit 11, I will therefore recommend the use of static code analysis and peer review via pull requests in Git.

This reflection helped me achieve learning outcome 2 because I became more aware of how different programming languages can affect the security of an application in development. In addition, I reached an understanding of how this can be managed.

References

Caller, B. (2021) Regexploit. Available from: https://github.com/doyensec/regexploit [Accessed 29 September 2021].

Cimpanu, C. (2019) Microsoft: 70 percent of all security bugs are memory safety issues. Available from: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ [Accessed 29 September 2021].

Fifield, D. (2019) A better zip bomb. Available from: https://www.bamsoftware.com/hacks/zipbomb/ [Accessed 1 November 2021].

Penner, C. (2016) Tail Recursion In Python. Available from: https://chrispenner.ca/posts/python-tail-recursion [Accessed 29 September 2021].

Python Software Foundation. (2021) Classes. Available from: https://docs.python.org/3/tutorial/classes.html#tut-private [Accessed 29 September 2021].

Bibiography

MIT BLOSSOMS. (2015) The Towers of Hanoi: Experiential Recursive Thinking. Available from: https://www.youtube.com/watch?v=UuIneNBbscc [Accessed 03 September 2021].