All posts must be (2) substantive responses with a minimum of 150 words each for Responses 1 and 2. Ensure you list and break down each response in a word document, along with its reference. Response provided should further discuss the subject or provide more insight. To further understand the response, below is the discussion post that’s discusses the responses. 100% original work and not plagiarized. Must meet deadline.

RESPONSE 1:

Defensive programming is the practice of creating or designing code in a way that will avoid issues before they can affect the system. The idea behind it is that developers will not be able to predict every sort of permutation of input or error that can affect the system they are designing. To combat this, programmers write their code in a way that will prevent or mitigate vulnerabilities that can be caused when unforeseen issues arise. A commonly seen example of defensive programming occurs when user input is required to query a database. SQL injections are a type of cyberattack that uses a vulnerability in the way the system process queries. It works when queries are not coded properly, and users are able to ‘inject’ SQL commands using the available input (Imperva, 2021). A common way this can happen is when user input is not formatted a certain way, i.e. made into a string before processing. Defensive programming in this instance would include ensuring all inputs are turned into strings or integers before querying. Additionally, ensuring that all invalid commands, or input that do not meet the correct criteria for querying, output a message instead of simply allowing them to go through the system is a good defense.

Defensive programming should definitely be a part of the architecture of any software or system. A common practice of defensive programming is ensuring that any unnecessary code is removed. Not only does this make a program require less resources to run, it reduces the chance of attackers using vulnerable code by removing it entirely if it is unnecessary. In that way, defensive programming allows for more efficient processes while also protecting systems from attack.

v/r

Anthony

Imperva. (2021, March 11). What is SQL injection: SQLI attack Example & Prevention Methods: Imperva. Learning Center. Retrieved December 30, 2021, from https://www.imperva.com/learn/application-security/sql-injection-sqli/#:~:text=SQL%20injection%2C%20also%20known%20as,lists%20or%20private%20customer%20details.

Wiesen, G. (2021, February 20). What is defensive programming? EasyTechJunkie. Retrieved December 30, 2021, from https://www.easytechjunkie.com/what-is-defensive-programming.htm

RESPONSE 2:

This week we were asked to discuss whether or not we would use defensive programming when developing procedures, processes, and architecture the guys work execution at the program or system level. At the risk of falling victim to stating the obvious, I believe I would implement defensive programming in the aforementioned scenarios. This is because my assumption is that a program I have decided to create or use to guide work execution serve some purpose for raising efficiency, decreasing cost, increasing efficacy, or some combination of the three. It is for this reason I assume such a program is vital if not critical to my organization’s success. By neglecting defensive programming, I would by extension buy more undue risk by utilizing said program.

Without proper defensive programming, software may pose a multitude of vulnerabilities that could allow a potential threat agent to gain unauthorized access to digital resources through exploitation of these vulnerabilities or even place an authorized user in a compromised position by inadvertently crashing or mishandling the program. Defensive programming mitigates the potential for an oversight in the program that could allow erroneous or malicious code to be executed thereby painting a proverbial target on the program in the system that runs it by any would be hackers. Improperly handled code could give way to a plethora of targeting techniques such as SQL injects, cross-site scripting, buffer overflow attacks. (Kristen, 2020)

V/R,
Jared

References:
Kristen, S. (2020). Cross site scripting (XSS). Cross Site Scripting (XSS) Software Attack | OWASP Foundation. Retrieved December 11, 2021, from https://owasp.org/www-community/attacks/xss/.