Updating headings on every page
This commit is contained in:
@@ -4,39 +4,39 @@ date: 2024-03-05
|
||||
draft: false
|
||||
---
|
||||
|
||||
# Introduction
|
||||
## Introduction
|
||||
|
||||
Prerequisites are incredibly important to any development project and was the [OWASP Top 10, Number 4, Insecure Design](https://owasp.org/Top10/A04_2021-Insecure_Design/). For the purpose of this document we will talk about it in context of *security implications*.
|
||||
|
||||
This ended up being too big of a topic for just two posts, so here is part 3. In {{< ref "code-complete-summations-pre-requisets-part-1.md" >}}, we looked at why pre-reqs are needed in general and how they apply to types of projects. In {{< ref "code-complete-summations-pre-requisets-part-2.md" >}} we looked at how various pre-reqs for architecture helps with security. In part 3 we'll look at resource and error management pre-reqs.
|
||||
|
||||
# Planning Comes First
|
||||
## Planning Comes First
|
||||
|
||||
As the saying goes a failure to plan is a plan to fail. Without a solid foundation, similar to building a house, the entire program can fall. With no plan in place, code can end up being added in a half-hazard way, causing code paths to become unknown or unintentionally created. These code paths then become more difficult to maintain.
|
||||
|
||||
Another saying that can apply is an ounce of preparation is worth a pound of cure. This can become even more poignant in software development, from a security perspective. From just a development perspective, this could mean saving time later trying to rewrite code that no longer fits or trying to shoehorn in code that doesn't quite fit. For security this can become a major issue if large security flaws are found in the software.
|
||||
|
||||
# Resource Management
|
||||
## Resource Management
|
||||
|
||||
Resource management includes not just how much memory or processing power is used, but also data base connections, threading, and file handles. These are vital to security as they are dealing with how data is accessed and processed.
|
||||
|
||||
By planning ahead with resource management a lot of the issues can be avoided from the beginning. If there is a failure to take this into account, the code will need to be retrofitted to fix any security issues. This could lead to inconsistent handling of resources or old code being left behind. Planning ahead is the best way to combat these security problems.
|
||||
|
||||
## Databases
|
||||
### Databases
|
||||
|
||||
Databases require a thoughtful setup. Using a secure password is only the start, encrypting the database (particularly file based DB, such as SQLite) should be considered. If this database is remote, having a secure connection is necessary.
|
||||
|
||||
In addition, how the data is accessed needs to be considered as well. This includes sanitizing using input, when and how to update data, and read and write sequences. Messing up these could cause leaks or corruption of data.
|
||||
|
||||
## Threading
|
||||
### Threading
|
||||
|
||||
Threading and data access is relevant for corrupted data. The data could be corrupted if read/write sequences are off. If two writes occur at the same time or data is read as a write is happening, the data could be corrupted. Shared variables across threads could also cause security issues sucha as use-after-free, double free, or access data outside of scope.
|
||||
|
||||
## File Handles
|
||||
### File Handles
|
||||
|
||||
In a previous post {{ < ref "secure-coding-in-c-summations-file-io.md" > }} we discussed in detail why file access is a security issue. By designing out from the beginning how files are going to be accessed will greatly reduce those security issues.
|
||||
|
||||
# Error Processing
|
||||
## Error Processing
|
||||
|
||||
Being able to handle errors properly is critical for security. There are a few questions that need to be answered that will have impact on how the software is architected:
|
||||
|
||||
@@ -47,6 +47,6 @@ Being able to handle errors properly is critical for security. There are a few q
|
||||
|
||||
These questions shouldn't be taken lightly. Each one should be considered since they could cause security issues. In addition just keeping things consistent is good for security since all developers will know what to expect from another developers code.
|
||||
|
||||
# Conclusion
|
||||
## Conclusion
|
||||
|
||||
Having a good design from the beginning can help prevent problems before they even arise. Then if bugs and security issues are found, having a good architecture will help to locate those issues faster.
|
||||
|
||||
Reference in New Issue
Block a user