Lesson 15: Summarizing Secure Application Development Concepts

Question 1

software exploitation

Answer 1

• means an attack that targets a vulnerability in OS or application software
• applications such as web servers, web browsers, email clients, and databases are often targeted
• application vulnerability is a design flaw that can cause the application security system to be circumvented or that will cause the application to crash

Question 2

zero-day exploit

Answer 2

• vulnerability that is exploited before the developer knows about it or can release a patch is called a zero-day exploit
• can be extremely destructive, as it can take the vendor a lot of time to develop a patch, leaving systems vulnerable for days, weeks, or even years

Question 3

input validation attack

Answer 3

• passes invalid data to the application, and because the input handling on the routine is inadequate, it causes the application or even the OS to behave in an unexpected way
• attack types:
  • Overflow—the attacker submits input that is larger than the variables assigned by the application to store it can cope with.

• Injection—the attacker embeds code within the input or appends code to it that executes when the server processes the submission.

Question 4

arbitrary code

Answer 4

attacker may be able to use the exploit to obtain sufficient privileges to run whatever malware (or arbitrary code) he or she chooses

Question 5

buffer overflow vulnerability

Answer 5

• attacker passes data that deliberately overfills the buffer (an area of memory) that the application reserves to store the expected data
• three principal exploits:
  • Stack overflow—the stack is an area of memory used by a program subroutine. It includes a return address, which is the location of the program that called the subroutine. An attacker could use a buffer overflow to change the return address, allowing the attacker to run arbitrary code on the system
• Heap overflow—a heap is an area of memory allocated by the application during execution to store a variable of some sort. A heap overflow can overwrite those variables, with unexpected effects. An example is a known vulnerability in Microsoft’s GDI+ processing of JPEG images
• Array index overflow—an array is a type of variable designed to store multiple values. It is possible to exploit unsecure code to load the array with more values than it expects, creating an exception that could be exploited

Question 6

integer overflow attack

Answer 6

• causes the target software to calculate a value that exceeds these bounds
• could also be used where the software is calculating a buffer size; if the attacker is able to make the buffer smaller than it should be, he or she may then be able to launch a buffer overflow attack

Question 7

race conditions

Answer 7

• occur when the outcome from execution processes is directly dependent on the order and timing of certain events, and those events fail to execute in the order and timing intended by the developer
• race condition vulnerability is typically found where multiple threads are attempting to write a variable or object at the same memory location
• race conditions have been used as an anti-virus evasion technique

Question 8

pointer

Answer 8

• reference to an object at a particular memory location
• attempting to access that memory address is called dereferencing
• pointer has been set to a null value (perhaps by some malicious process altering the execution environment), this creates a null pointer type of exception and the process will crash. Programmers can use logic statements to test that a pointer is not null before trying to use it

Question 9

memory leaks

Answer 9

particularly serious in service/background applications, as they will continue to consume memory over an extended period. Memory leaks in the OS kernel are also extremely serious. A memory leak may itself be a sign of a malicious or corrupted process

Question 10

Dynamic Link Library (DLL)

Answer 10

• binary package that implements some sort of standard functionality, such as establishing a network connection or performing cryptography
• main process of a software application is likely to load (or call) several DLLs during the normal course of operations

Question 11

DLL injection

Answer 11

• not a vulnerability of an application but of the way the operating system allows one process to attach to another
• functionality can be abused by malware to force a legitimate process to load a malicious link library
• link library will contain whatever functions the malware author wants to be able to run
• malware uses this technique to move from one host process to another to avoid detection

Question 12

refactoring

Answer 12

means that the code performs the same function by using different methods (control blocks, variable types, and so on)

Question 13

shim

Answer 13

• code library that intercepts and redirects calls to enable legacy mode functionality is called a shim
• shim must be added to the registry and its files (packed in a shim database/.SDB file) added to the system folder

Question 14

arbitrary code execution

Answer 14

purpose of the attacks against application or coding vulnerabilities is to allow the attacker to run his or her own code on the system

Question 15

remote code execution

Answer 15

• code is transmitted from one machine to another
• code would typically be designed to install some sort of Trojan or to disable the system in some way (Denial of Service)

Question 16

privilege escalation

Answer 16

• Vertical privilege escalation (or elevation) is where a user or application can access functionality or data that should not be available to them. For instance, a user might have been originally assigned read-only access (or even no access) to certain files, but after vertical escalation, the user can edit or even delete the files in question.
• Horizontal privilege escalation is where a user accesses functionality or data that is intended for another user. For instance, a user might have the means to access another user’s online bank account.

Question 17

SQL injection attack

Answer 17

• attempts to insert an SQL query as part of user input
• attack can either exploit poor input validation or unpatched vulnerabilities in the database application
• if successful, this could allow the attacker to extract or insert information into the database or execute arbitrary code on the remote system using the same privileges as the database application

Question 18

directory traversal

Answer 18

• another common input validation attack
• attacker submits a request for a file outside the web server’s root directory by using the command to navigate to the parent directory (../). This attack can succeed if the input is not filtered properly and access permissions on the file are the same as those on the web server root.
• command injection attack attempts to run OS shell commands from the browser | as with directory traversal, the web server should normally be able to prevent commands from operating outside of the server’s directory root and to prevent commands from running with any other privilege level than the web “guest” user (who is normally granted only very restricted privileges). A successful command injection attack would find some way of circumventing this security (or find a web server that is not properly configured).

Question 19

transitive access

Answer 19

• describes the problem of authorizing a request for a service that depends on an intermediate service
• Designing the trust relationships between these three parties is complicated:
• The merchant site could impersonate the end user to obtain publisher site services fraudulently.
• The end user could exploit weaknesses in the merchant site to obtain unauthorized services from the publisher site.

Question 20

Cross-Site Scripting (XSS)

Answer 20

• one of the most powerful input validation exploits
• attack described is a reflected or non-persistent XSS attack
• stored (or persistent) XSS attack aims to insert code into a back-end database used by the trusted site.
• typical attack would proceed as follows:
  1. The attacker identifies an input validation vulnerability in the trusted site.
  2. The attacker crafts a URL to perform a code injection against the trusted site. This could be coded in a link from the attacker’s site to the trusted site or a link in an email message.
  3. When the user clicks the link, the trusted site returns a page containing the malicious code injected by the attacker. As the browser is likely to be configured to allow the site to run scripts, the malicious code will execute.
  4. The malicious code could be used to deface the trusted site (by adding any sort of arbitrary HTML code), steal data from the user’s cookies, try to intercept information entered into a form, or try to install malware. The crucial point is that the malicious code runs in the client’s browser with the same permission level as the trusted site.

Question 21

Document Object Model (DOM)

Answer 21

client-side scripts use the Document Object Model (DOM) to modify the content and layout of a web page. For example, the “document.write” method enables a page to take some user input and modify the page accordingly. An attacker could submit a malicious script as input and have the page execute the script. Such exploits can be very powerful as they run with the logged in user’s privileges of the local system.

Question 22

cookie

Answer 22

• various mechanisms have been used to preserve this sort of stateful information
• created when the server sends an HTTP response header with the cookie
• cookies are either non-persistent (or session) cookies, in which case they are stored in memory and deleted when the browser instance is closed, or persistent, in which case they are stored on the hard drive until deleted by the user or pass a defined expiration date
• replaying–Session IDs are often generated using predictable patterns (such as IP address with the date and time), making the session vulnerable to eavesdropping and possibly hijacking, by replaying the cookie to re-establish the session

Question 23

Cross-Site Request Forgery (XSRF)

Answer 23

• exploit applications that use cookies to authenticate users and track sessions
• to work, the attacker must convince the victim to start a session with the target site. The attacker must then pass an HTTP request to the victim’s browser that spoofs an action on the target site
• confused deputy attack–if the target site assumes that the browser is authenticated because there is a valid session cookie and doesn’t complete any additional authorization process on the attacker’s input (or if the attacker is able to spoof the authorization), it will accept the input as genuine

Question 24

Locally Shared Objects (LSOs) or Flash cookies

Answer 24

data that is stored on a user’s computer by websites that use Adobe® Flash® Player. A site may be able to track a user’s browsing behavior through LSOs, causing a breach of privacy. Even if a user wipes tracking objects from their browser, LSOs may remain on their system.

Question 25

HTTP Response Splitting or CRLF injection

Answer 25

attacker would craft a malicious URL and convince the victim to submit it to the web server. This could be encoded in something like an image tag, so the user may not have to choose to click a link.

Question 26

Man-in-the-Browser (MitB) attack

Answer 26

• where the web browser is compromised by installing malicious plug-ins or scripts or intercepting API calls between the browser process and DLLs
• Browser Exploitation Framework (BeEF) (https://beefproject.com) is one well-known MitB tool
• Clickjacking–an attack where what the user sees and trusts as a web application with some sort of login page or form contains a malicious layer or invisible iFrame that allows an attacker to intercept or redirect user input. Clickjacking can be launched using any type of compromise that allows the adversary to run JavaScript (XSS, CSRF, or MitB, for instance). Clickjacking can be mitigated by using HTTP response headers that instruct the browser not to open frames from different origins (domains) and by ensuring that any buttons or input boxes on a page are positioned on the top-most layer.

Question 27

Software Development Lifecycle (SDLC)

Answer 27

• divides the creation and maintenance of software into discrete phases
• SDLC principal-waterfall model phases:
  • Requirements—capture everything that the system must do and the levels to which it must perform.
• Design—develop a system architecture and unit structure that fulfills the requirements.
• Implementation—develop the system units as programming code.
• Verification—ensure the implementation meets the requirements and design goals.
• Testing—integrate the units and ensure they work as expected.
• Maintenance—deploy the system to its target environment and ensure that it is operated correctly.
• Retirement—remove (deprovision) the system and any dependencies if they are no longer used.
• SDLC principal-agile model phases:
  • Concept—devise the initial scope and vision for the project and determine its feasibility.
• Inception—identify stakeholders and support for the project and start to provision resources and determine requirements.
• Iteration—prioritize requirements and work through cycles of designing, developing, testing, and test deploying solutions to the project goals, adapting to changing requirements, priorities, and resources as needed.
• Transition—perform final integration and testing of the solution and prepare for deployment in the user environment.
• Production—ensure that the solution operates effectively.
• Retirement—deprovision the solution and any environmental dependencies.

Question 28

secure development

Answer 28

• A legacy software design process might be heavily focused on highly visible elements, such as functionality, performance, and cost. You can also envisage a Security Development Lifecycle (SDLC) running in parallel or integrated with the focus on software functionality and usability.
• Secure development means that at each phase, security considerations are accounted for:
• Planning—train developers and testers in security issues, acquire security analysis tools, and ensure the security of the development environment.
• Requirements—determine needs for security and privacy in terms of data processing and access controls.
• Design—identify threats and controls or secure coding practices to meet the requirements.
• Implementation—perform “white box” source code analysis and code review to identify and resolve vulnerabilities.
• Testing—perform “black box” or “gray box” analysis to test for vulnerabilities in the published application (and its publication environment).
• Deployment—ensure source authenticity of installer packages and publish best practice configuration guides.
• Maintenance—ongoing security monitoring and incident response procedures, patch development and management, and other security controls.

Question 29

secure staging deployment concepts

Answer 29

• during development, the code is normally passed through several different environments:
• Development—The code will be hosted on a secure server. Each developer will check out a portion of code for editing on his or her local machine. The local machine will normally be configured with a sandbox for local testing. This ensures that whatever other processes are being run locally do not interfere with or compromise the application being developed.
• Test/integration—In this environment, code from multiple developers is merged to a single master copy and subjected to basic unit and functional tests (either automated or by human testers). These tests aim to ensure that the code builds correctly and fulfills the functions required by the design.
• Staging—This is a mirror of the production environment but may use test or sample data and will have additional access controls so that it is only accessible to test users. Testing at this stage will focus more on usability and performance.
• Production—The application is released to end users.

Question 30

validate integrity of each coding environment

Answer 30

• Compromise in any environment could lead to the release of compromised code.
• Sandboxing—Each development environment should be segmented from the others. No processes should be able to connect to anything outside the sandbox. Only the minimum tools and services necessary to perform code development and testing should be allowed in each sandbox.
• Secure baseline—Each development environment should be built to the same specification, possibly using automated provisioning.
• Integrity measurement—This process determines whether the development environment varies from the secure baseline.

Question 31

provisioning

Answer 31

• process of deploying an application to the target environment, such as enterprise desktops, mobile devices, or cloud infrastructure
• enterprise provisioning manager might assemble multiple applications in a package
• instance: alternatively, the OS and applications might be defined as a single instance for deployment on a virtualized platform

Question 32

deprovisioning

Answer 32

process of removing an application from packages or instances

Question 33

version control

Answer 33

• ID system for each iteration of a software product
• supports the change management process for software development projects
• continuous integration is the principle that developers should commit updates often (every day or sometimes even more frequently)

Question 34

normalization

Answer 34

means that a string is stripped of illegal characters or substrings and converted to the accepted character set. This ensures that the string is in a format that can be processed correctly by the input validation routines

Question 35

canonicalization attack

Answer 35

• disguise the nature of the malicious input
• refers to the way the server converts between the different methods by which a resource such as a file path or URL may be represented and submitted to the simplest (or canonical) method used by the server to process the input

Question 36

fuzzing

Answer 36

• means of testing that an application’s input validation routines work well
• means that the test or vulnerability scanner generates large amounts of deliberately invalid and/or random input and records the responses made by the application
• form of “stress testing”

Question 37

client-side validation

Answer 37

• client will always be more vulnerable to some sort of malware interfering with the validation process
• client-side validation is usually restricted to informing the user that there is some sort of problem with the input before submitting it to the server
• even after passing client-side validation, the input will still undergo server-side validation before it can be posted (accepted)
• relying on client-side validation only is poor programming practice

Question 38

server-side validation

Answer 38

main issue with server-side validation is that it can be time-consuming, as it may involve multiple transactions between the server and client

Question 39

XSS/XSRF prevention

Answer 39

input validation should be enough to defeat most cross-site style attacks. The other consideration is for the application to use secure authentication and authorization procedures. Naïve methods of recording sessions, such as unencrypted cookies, should be deprecated. Even if a user has authenticated, any actions the user attempts to perform should be properly authorized using some sort of secure token that an attacker cannot spoof or replay

Question 40

handler

Answer 40

programmer will have written an error or exception handler to dictate what the application should then do. Each procedure can have multiple error handlers. Some handlers will deal with anticipated errors and exceptions; there should also be a catch-all handler that will deal with the unexpected.

Question 41

memory management

Answer 41

many arbitrary code attacks depend on the target application having faulty memory management procedures. This allows the attacker to execute his or her own code in the space marked out by the target application. There are known unsecure practices for memory management that should be avoided and checks for processing untrusted input, such as strings, to ensure that it cannot overwrite areas of memory

Question 42

secure code usage

Answer 42

program may make use of existing code in the following ways:

• Code reuse—using a block of code from elsewhere in the same application or from another application to perform a different function (or perform the same function in a different context). The risk here is that the copy and paste approach causes the developer to overlook potential vulnerabilities (perhaps the function’s input parameters are no longer validated in the new context).
• Third-party library—a binary package (such as a Dynamic Link Library) that implements some sort of standard functionality, such as establishing a network connection or performing cryptography. Each library must be monitored for vulnerabilities and patched promptly.
• Software Development Kit (SDK)—the programming environment used to create the software might provide sample code or libraries of pre-built functions. As with other third-party libraries or code, it is imperative to monitor for vulnerabilities.

Question 43

stored procedure

Answer 43

part of a database that executes a custom query. The procedure is supplied an input by the calling program and returns a pre-defined output for matched records. This can provide a more secure means of querying the database. Any stored procedures that are part of the database but not required by the application should be disabled

Question 44

code signing

Answer 44

• principal means of proving the authenticity and integrity of code (an executable or a script)
• developer creates a cryptographic hash of the file then signs the hash using his or her private key
• program is shipped with a copy of the developer’s code signing certificate, which contains a public key that the destination computer uses to read and verify the signature
• OS then prompts the user to choose whether to accept the signature and run the program

Question 45

unreachable code

Answer 45

• part of application source code that can never be executed
• Dead code is executed but has no effect on the program flow
• Unreachable and dead code should be removed from the application to forestall the possibility that it could be misused in some way. The presence of unreachable/dead code can indicate that the application is not being well maintained.

Question 46

data exposure

Answer 46

fault that allows privileged information (such as a token, password, or PII) to be read without being subject to the appropriate access controls. Applications must only transmit such data between authenticated hosts, using cryptography to protect the session. When incorporating encryption in your code, it’s important to use encryption algorithms and techniques that are known to be strong, rather than creating your own

Question 47

obfuscation/camouflage

Answer 47

• code can be made difficult to analyze by using an obfuscator, which is software that randomizes the names of variables, constants, functions, and procedures, removes comments and white space, and performs other operations to make the compiled code physically and mentally difficult to read and follow. This sort of technique might be used to make reverse engineering an application more difficult and as a way of disguising malware code.
• Another option is to encrypt the code, but if the code is to run, the encryption key must be made available on the host at some point. This gives a malicious process on the same host the chance of recovering the key from memory.

Question 48

design review

Answer 48

ensure that security is a requirement for the application. One of the design goals of a secure application should be to reduce the attack surface. The attack surface is all the ways that a user (including malicious users) can interact with the application. This includes ways that the application designer has foreseen, such as form fields and Application Programming Interfaces (API)—methods other applications can call—and those that they have not. As well as simplifying the application, it is also important to reduce the attack surface of the host OS and network

Question 49

code review

Answer 49

an in-depth examination of the way the application is written to ensure that it is well written and does not expose the application to known input validation or injection attacks

Question 50

architecture review

Answer 50

analyze the systems on which the application depends. This could include the underlying OS and database application, programming language and development environment, client platform (PC and/or mobile), browsers, and plug-ins, and so on

Question 51

Verification and Validation (V&V)

Answer 51

• Verification is a compliance testing process to ensure that the product or system meets its design goals.
• Validation is the process of determining whether the application is fit-for-purpose (so for instance, its design goals meet the user requirements).

Question 52

compiled

Answer 52

• compiler tests that the code is well-formed
• well-formed does not mean that the code will execute without errors, just that its syntax is compliant with the requirements of the programming language

Question 53

runtime environment

Answer 53

• used for functional testing
• runtime environment will use one of two approaches for execution on a host system:
• Compiled code is converted to binary machine language that can run independently on the target OS.
• Interpreted code is packaged pretty much as is but is compiled line-by-line by an interpreter. This offers a solution that is platform independent because the interpreter resolves the differences between OS types and versions.

Question 54

static code analysis (or source code analysis)

Answer 54

• performed against the application code before it is packaged as an executable process
• analysis software must support the programming language used by the source code

Question 55

code review or manual peer review

Answer 55

human analysis of software source code is described as a code review or as a manual peer review. It is important that the code be reviewed by developers (peers) other than the original coders to try to identify oversights, mistaken assumptions, or a lack of knowledge or experience. It is important to establish a collaborative environment in which reviews can take place effectively.

Question 56

dynamic analysis

Answer 56

means that the application is tested under “real world” conditions using a staging environment

Question 57

fuzzing

Answer 57

• technique designed to test software for bugs and vulnerabilities.
• three types of fuzzers, representing different ways of injecting manipulated input into the application:
• Application UI—identify input streams accepted by the application, such as input boxes, command line switches, or import/export functions.
• Protocol—transmit manipulated packets to the application, perhaps using unexpected values in the headers or payload.
• File format—attempt to open files whose format has been manipulated, perhaps manipulating specific features of the file.
• concept of stress testing an application to see how an application performs under extreme performance or usage scenarios

Question 58

Agile operations

Answer 58

Agile development principles can also be applied to system administration/operations tasks (Agile operations). Amongst other principles, Agile addresses the idea that resiliency, the ability to sustain performance despite failures, is a better and more achievable goal than the elimination of faults. This principle is referred to as fail fast (and learn quickly). The concept is that faults are much better identified in a production environment and that this is a more effective way to improve an application, as long as developers are able to respond quickly.

Question 59

DevOps

Answer 59

• means that there is much more collaboration between developers and system administrators
• The concepts of Agile operations and DevOps support a few new approaches to deploying code:
• Immutable infrastructure—This approach first strictly divides data from the components processing data. Once designed and provisioned as instances, the components are never changed or patched in place. Deploying a patch or adding a new application means building a new instance and deploying that.
• Infrastructure as Code—This is the principle that when deploying an application, the server instance supporting the application can be defined and provisioned through the software code. Imagine a setup program that not only installs the application but also creates a VM and OS on which to run the application.
• Security automation—The concept of scripted or programmed infrastructure can also be applied to security infrastructure (firewalls, IDS, SIEM, and privilege management).