CHAPTER 5 Application Security
Provide examples of device hardening methods that apply to back office applications that run on servers:
*Database server software*, *email server software*, *Microsoft SQL server software*, *Microsoft Exchange server software*, *FTP server software*, and *HTTP web server software* are all considered insecure OOTB, and must be hardened. For example, many types of database server software and FTP server software are configured with a default Administrator account with a blank password. This creates an easy threat vector if the attacker knows the server software used by your organization. To harden these devices, be sure to: *#* Disable unnecessary accounts *#* Change all default information *#* Configure strong passwords
*5.3.3.8* Memory/Buffer Vulnerabilities
*5.3.3.8* Memory/Buffer Vulnerabilities
*5.3.3.9* Arbitrary Code Execution/Remote Code Execution
*5.3.3.9* Arbitrary Code Execution/Remote Code Execution
Describe the steps involved in *Compilation*:
*Compilation*: high-level *source code* is translated into low-level *machine code* by a *compiler*. The result of a successful compilation is an *executable*. The compilation process consists of three phases: *# Front End*: *>>* Preprocessing *>>* Lexical Analysis *>* Scanning *>* Evaluating *>>* Syntax Analysis (Parsing) *>>* Semantic Analysis *# Middle End*: *>>* Analysis *>>* Low-Level Language Optimizations *# Back End*: *>>* Machine-Dependent Optimizations *>>* Code Generation
Key Terms *Directory Traversal*:
A directory traversal (or path traversal) consists in exploiting insufficient security validation / sanitization of user-supplied input file names, such that characters representing "traverse to parent directory" are passed through to the file APIs. The goal of this attack is to use an affected application to gain unauthorized access to the file system. This attack exploits a lack of security (the software is acting exactly as it is supposed to) as opposed to exploiting a bug in the code. Directory traversal is also known as the ../ (dot dot slash) attack, directory climbing, and backtracking. Some forms of this attack are also canonicalization attacks.
Key Terms *Backdoor*:
A method of bypassing normal authentication and other security mechanisms in place.
Key Terms *Cookies*:
A small piece of data (up to 4 Kb) sent from a website and stored on the user's computer by the user's web browser while the user is browsing. Designed to be a reliable mechanism to remember stateful information, or to record browsing activity, they can also be used to remember information entered into form fields.
Key Terms *Memory Leak*:
a computer program incorrectly manages memory allocations in such a way that memory which is no longer needed is never released. Although the memory manager can free up unused memory, it cannot clear memory it believes is in use. This eventually leads to irreversible hanging. To deal with this problem, garbage collection libraries should be added to C and C++.
Key Terms *Address Space Layout Randomization (ASLR)*:
a computer security technique involved in preventing exploitation of memory corruption vulnerabilities. In order to prevent an attacker from reliably jumping to a particular location in memory, ASLR randomly arranges the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap and libraries.
Key Terms *Remote Code Execution (RCE)*:
a discovered vulnerability that allows the attacker to remotely inject and execute shellcode, that gives the attacker an easy way to manually run remote arbitrary commands. The process has also been demonstrated by coding enthusiasts to allow the user to write code of their own in assembly, using the system to create and activate scripts. One user, with the help of emulators and programmed inputs, managed to code and create a primitive version of the game Pong in a copy of Super Mario World, as well as Flappy Bird, using arbitrary code execution. Arbitrary (Remote) Code Execution is the most powerful effect a bug can have, because it allows an attacker to completely take over the process. From there the attacker can potentially take complete control over the machine the process is running on. Arbitrary code execution is commonly achieved through control over the instruction pointer (such as a jump or a branch) of a running process. The instruction pointer points to the next instruction in the process that will be executed. Control over the value of the instruction pointer gives control over which instruction is executed next. In order to execute arbitrary code, many exploits inject code into the process and use a vulnerability to change the instruction pointer to have it point to the injected code. The injected code will automatically be executed. Once the invader can execute arbitrary code directly on the OS, there is often an attempt at a privilege escalation exploit to gain additional control. This may involve the kernel itself or an account such as Administrator, SYSTEM, or root. With or without this enhanced control, exploits have the potential to do severe damage or turn the computer into a zombie. Privilege escalation helps hide the attack from the system administrator.
Key Terms *Software Development Life Cycle (SDLC)*:
a framework that defines tasks performed at each step in the software development process. SDLC is a structure followed by a development team within the software organization. It consists of a detailed plan describing how to develop, maintain and replace specific software.
Key Terms *Structured Exception Handling (SEH)*:
a mechanism for handling both hardware and software exceptions. Your code will handle hardware and software exceptions identically. This enables you to have complete control over the handling of exceptions, provides support for debuggers, and may be used across all programming languages and machines.
Explain the concept of *Termination Handling*:
a mechanism which enables you to ensure that whenever a guarded body of code is executed, a specified block of termination code is also executed. The termination code is executed regardless of how the flow of control leaves the guarded body. For example, a termination handler can guarantee that clean-up tasks are performed even if an exception or some other error occurs while the guarded body of code is being executed.
Key Terms *Black-Box Testing*:
a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied to virtually every level of software testing: unit, integration, system and acceptance. It is sometimes referred to as specification-based testing.
Key Terms *Agile Model*:
a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles, that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast changing environment.
Key Terms *Waterfall Model*:
a popular version of the systems development life cycle model (SDLC) for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential.
Key Terms *Threat Modeling*:
a procedure for optimizing network security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system.
Key Terms *Fuzz Testing (Fuzzing)*:
a quality assurance technique used to discover coding errors and security loopholes in software, operating systems or networks. It involves inputting massive amounts of random data, called fuzz, to the test subject in an attempt to make it crash.
Key Terms *User Account Control (UAC)*:
a security feature of Windows which helps prevent unauthorized changes to the operating system. These changes can be initiated by applications, users, viruses or other forms of malware.
Key Terms *Sandbox*:
a testing environment that isolates untested code changes from the production environment or repository. Sandboxing protects live environments from changes that could be (intentionally or unintentionally) damaging, or difficult to revert. Sandboxes replicate at least the minimal environmental variables needed to test the code in development.
*5.3.3* Programming Testing Methods
*5.3.3* Programming Testing Methods
*5.3.3.1* White-box and Black-box Testing
*5.3.3.1* White-box and Black-box Testing
*5.3.3.10* XSS and XSRF
*5.3.3.10* XSS and XSRF
*5.3.3.11* More Code Injection Examples
*5.3.3.11* More Code Injection Examples
*5.3.3.12* Directory Traversal
*5.3.3.12* Directory Traversal
*5.3.3.13* Zero Day Attack
*5.3.3.13* Zero Day Attack
*5.3.3.2* Compile-Time Errors Versus Runtime Errors
*5.3.3.2* Compile-Time Errors Versus Runtime Errors
*5.3.3.3* Input Validation
*5.3.3.3* Input Validation
*5.3.3.4* Static and Dynamic Code Analysis
*5.3.3.4* Static and Dynamic Code Analysis
*5.3.3.5* Fuzz Testing
*5.3.3.5* Fuzz Testing
*5.3.3.6* Programming Vulnerabilities and Attacks
*5.3.3.6* Programming Vulnerabilities and Attacks
*5.3.3.7* Backdoors
*5.3.3.7* Backdoors
*5.1.2.1* Basic Browser Security
*5.1.2.1* Basic Browser Security
*5.1.2.2* Cookies
*5.1.2.2* Cookies
*5.1.2.3* LSOs
*5.1.2.3* LSOs
*5.1.2.4* Add-ons
*5.1.2.4* Add-ons
*5.1.2.5* Advanced Browser Security
*5.1.2.5* Advanced Browser Security
*5.2* Securing Other Applications
*5.2* Securing Other Applications
*5.3.1* Software Development Life Cycle
*5.3.1* Software Development Life Cycle
List the security principles that should be incorporated into any SDLC:
*# Assess the Landscape*: Understand what the customer actually wants. This prevents you from having to code patches and fixes for problems the customer never asked for. *# Secure the Software from Step 1*: Integrate a trusted security model into your SDLC, and use best practices to identify security flaws from the beginning to create less work. *# Implement the Principle of Least Privilege*: Software should be coded such that users and processes have access to only what they need. *# Separate Privileges*: Access to objects should depend on multiple conditions (for example, authentication plus an encrypted key). *# Implement the Principle of Defense in Depth*: More security controls are better than fewer security controls. The layering of defense in secure coding may take the form of validation, encryption, auditing, and/or special authentication techniques. *# Applications Should Never Trust User Input*: Input should be validated carefully. *# Minimize the Attack Surface Area*: Every additional feature that a programmer adds to an application increases the size of the attack surface and increases risk. Unnecessary functions should be removed, and necessary functions should require authorization. *# Establish Secure Defaults*: OOTB defaults should be as secure as possible. If possible, user password complexity and password aging policies should be configured by the programmer, not the user. Permissions should default to no access and should be granted only as needed. *# Fail Securely*: Error handling/exception handling code should be checked thoroughly so that a malicious user can't find any additional information about the system. *# Fix Security Issues Correctly*: Found security vulnerabilities should be tested, documented, and understood. Patches should be developed to fix the problem, but should not cause other issues or application regression.
Define the term *Code Injection*. Describe the process of *SQL Injection*, *XML Injection*, and *LDAP Injection*:
*# Code Injection*: the exploitation of a computer bug that is caused by processing invalid data. Injection is used by an attacker to introduce (inject) code into a vulnerable computer program and change the course of execution. Code injection vulnerabilities (injection flaws) occur when an application sends untrusted data to an interpreter. Injection flaws are most often found in SQL, LDAP, XPath, or NoSQL queries; OS commands; XML parsers, SMTP headers, program arguments. Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover. Code injection techniques are popular in system hacking or cracking to gain information, privilege escalation or unauthorized access to a system. *# SQL Injection*: Relational databases, managed by a Relational Database Management System (RDBMS), are usually written in Structured Query Language (SQL) or Microsoft's version of SQL (MySQL). By injecting SQL code into a database that has not been configured to deflect or refuse it, SQL injection exploits a security vulnerability and allows the user to query a database from the web, change database information, and even delete all files. Some databases don't use SQL or My SQL, and are called NoSQL databases. While they are resistant to SQL injection attacks, there are NoSQL injection attacks as well. An example of a NoSQL injection attack is the *JSON Injection Attack*. *# XML Injection*: an attack technique used to manipulate or compromise the logic of an XML application or service. The injection of unintended XML content and/or structures into an XML message can alter the intend logic of the application. *# LDAP Injection*: an attack technique used to exploit web sites that construct LDAP statements from user-supplied input. Lightweight Directory Access Protocol (LDAP) is an open-standard protocol for both querying and manipulating X.500 directory services. *Note:* The best way to defend against code injection/command injection techniques in general is by implementing input validation during the development, testing, and maintenance phases of the SDLC
Compare and contrast the terms *Compilation Error*, *Linker Error*, and *Run-time Error*:
*# Compilation Error*: an error that occurs when a compiler fails to compile a piece of computer program source code, either due to errors in the code, or, more unusually, due to errors in the compiler itself. Compilation error messages often helps programmers *debug* the source code. Examples of compilation errors include *syntax errors* and *type-checking errors*. *# Linker Error*: the compilation was successful, but some necessary function or library cannot be found, or does not exist. *# Run-time Error*: when you run a program (after it has successfully compiled and linked), an error occurs. There are two types of run-time errors: *>> Fatal Errors*: The executable crashes *>> Logic Errors*: Your program does not run as expected Run-time errors include *buffer overflows*, *division by zero*, *invalid memory addressing*, or *invalid parameter values*
Describe the four *Program Lifecycle Phases* involved in executing a program:
*# Compile Time*: high-level *source code* is translated into low-level *machine code* by a *compiler*. The result of a successful compilation is an *executable*. *# Link Time*: a *linker* takes one or more object files generated by a compiler and combines them into a single executable file, library file, or other object file. There are two types of link files: *>> Static Library* or *Statically-Linked Library*: a set of routines, external functions and variables which are resolved in a caller at compile-time and copied into a target application by a compiler, linker, or binder, producing an object file and a stand-alone executable. *>> Dynamic Library* or Dynamically-Linked Library*: the OS loads and links the shared libraries needed by an executable at run time, by copying the content of libraries from persistent storage to RAM. *# Load Time*: a *loader* (part of the OS) reads the contents of the executable file containing the program instructions into memory. Once loading is complete, the operating system starts the program by passing control to the loaded program code. *# Run Time*: the time during which a program is running (executing)
Once the devices in your organization have been configured according to the principle of least privilege, the applications that users are allowed to work with must be secured. Provide examples of these common user applications, and the safeguards that must be put in place for them:
*# Outlook*: *>>* Install the latest Office update or service pack. (This applies to all Office suite applications.) *>>* Keep Office up to date with Windows Update. (This also applies to all Office suite applications.) *>>* Consider an upgrade to a newer version of Office, if the currently used one is no longer supported. *>>* Increase the junk e-mail security level or use a whitelist. *>>* Read messages in plain text instead of HTML. *>>* Enable attachment blocking. *>>* Use a version that enables Object Model Guard functionality, or download it for older versions. *>>* Password protect any .PST files. *>>* Use strong passwords for Microsoft accounts if using web-based Outlook applications. *>>* Use encryption: *>* Consider encrypting the authentication scheme, and possibly other traffic, including message traffic between Outlook clients and Exchange servers. *>* Consider a digital certificate. Secure Password Authentication (SPA) can be used to secure the login, and S/MIME and PGP/GPG can be used to secure actual e-mail transmissions. Or, in the case of web-based e-mail, use SSL or TLS for encryption. *# Word*: *>>* Consider using passwords for opening or modifying documents. *>>* Use read-only or comments only (tracking changes) settings. *>>* Consider using a digital certificate to seal the document. *# Excel*: *>>* Use password protection on worksheets. *>>* Set macro security levels. *>>* Consider Excel encryption.
*5.3* Secure Programming
*5.3.1* Software Development Life Cycle *5.3.2* Core SDLC and DevOps Principles *5.3.3* Programming Testing Methods *5.3.3.1* White-box and Black-box Testing *5.3.3.2* Compile-Time Errors Versus Runtime Errors *5.3.3.3* Input Validation *5.3.3.4* Static and Dynamic Code Analysis *5.3.3.5* Fuzz Testing *5.3.3.6* Programming Vulnerabilities and Attacks *5.3.3.7* Backdoors *5.3.3.8* Memory/Buffer Vulnerabilities *5.3.3.9* Arbitrary Code Execution/Remote Code Execution *5.3.3.10* XSS and XSRF *5.3.3.11* More Code Injection Examples *5.3.3.12* Directory Traversal *5.3.3.13* Zero Day Attack
*5.3.2* Core SDLC and DevOps Principles
*5.3.2* Core SDLC and DevOps Principles
List examples of *Security through Obscurity*:
*# Security through Obscurity* is the concept of reducing the attack surface by employing additional techniques designed to hide or obscure the target, layered on top of traditional security measures. The following are considered Security through Obscurity techniques: *# Obfuscation*: Deliberately complicating the source code or system to make it more difficult to understand. This conceals its purpose to prevent tampering and reverse engineering. *# Camouflage*: To disguise or hide the presence of a key piece of code to make it better blend in with its surroundings. *# Steganography*: the practice of concealing messages or information within other nonsecret text or data. *# Moving Target Defense*: the concept of controlling change across multiple system dimensions in order to increase uncertainty and apparent complexity for attackers, reduce their window of opportunity and increase the costs of their probing and attack efforts. *# Deception Technology*: a category of security tools and techniques designed to prevent an attacker who has already entered the network from doing damage. Deception technology products work by distributing decoys that mimic genuine IT assets throughout the network.
Compare and contrast *Static Code Analysis* and *Dynamic Code Analysis*:
*# Static Code Analysis*: Code is analyzed without being executed, either visually or with the aid of automated tools. Static code analysis is meant to locate major code flaws. *# Dynamic Code Analysis*: Code is analyzed through testing (execution). This locates minor defects and vulnerabilities that otherwise would not be seen. *Note:* The combination of *Static Code Analysis* and *Dynamic Code Analysis* is referred to as *White-Box Testing*.
What four actions should you take to protect your organization from dangerous web traffic?
*#* Develop and implement a strong security policy *#* Train your users *#* Use a proxy and content filter *#* Protect your machines from malware
How can you configure a browser to prefer connections to HTTP proxy servers?
*#* Most browsers will have an option in their settings menu that, if accessed, redirects you to the *Internet Properties* configuration options window in the OS. *#* Within that window, navigate to the *LAN Settings* window. From here, you should see the option to configure a proxy server. *Note:* This setting can also be configured within an Organizational Unit (OU) Group Policy object on the Domain Controller (central server), if one exists. This way, the proxy settings only have to be configured once, but can then be set to the entire organization.
List the actions you should take, and those you should avoid, when planning your organization's browser security configuration:
*#* Purposefully choose the browser that best suits your organization's needs: *>>* MacOS uses Safari *>>* Linux uses Firefox, but may also use Chrome or Opera *>>* Windows uses Microsoft Edge, but may also use Chrome, Opera, or Firefox *#* Avoid using the latest version of your chosen browser. These versions often must be patched to fix security flaws. *#* Consider how quickly each browser company fixes vulnerabilities, and how secure each browser is generally.
Compare and Contrast the *Waterfall Model*, the *V-Shaped Model*, and the *Agile Model*:
*#* The *Waterfall Model* process is linear, sequential, and ordered. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction (downwards like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. *#* The *V-Shaped Model* process is considered an extension of the Waterfall Model. The left side of the V represents creation (development) of the system, product, or code. The right side represents integration, validation, and monitoring. *#* The *Agile Model* is focused on: *>>* customer satisfaction *>>* cooperation *>>* simplicity *>>* working in small teams *>>* setting and meeting incremental (instead of large) goals *>>* face-to-face communication *>>* the ability to organize and complete quality work with or without managerial oversight
What measures should you take to configure a browser to provide basic browser security?
*#* Update the browser to a stable version *#* Install a safe pop-up blocker and ad blocker *#* Configure security zones that match your firewall's trust zones *#* Disable ActiveX, Flash, and JavaScript
List advanced browser security methods:
*#* Use incognito mode (private browsing), or else clear the cache of stored information on exit *#* Do not save passwords in the browser *#* Require a minimum version of SSL or TLS for a connection to be allowed. *#* Consider connecting through a VPN and/or virtual machine *#* Implement Group Policies from a Domain Controller
*CHAPTER 5* Application Security
*5.1* Securing the Browser *5.1.1* General Browser Security Procedures *5.1.1.1* Implement Policies *5.1.1.2* Train Your Users *5.1.1.3* Use a Proxy and Content Filter *5.1.1.4* Secure Against Malicious Code *5.1.2* Web Browser Concerns and Security Methods *5.1.2.1* Basic Browser Security *5.1.2.2* Cookies *5.1.2.3* LSOs *5.1.2.4* Add-ons *5.1.2.5* Advanced Browser Security *5.2* Securing Other Applications *5.3* Secure Programming *5.3.1* Software Development Life Cycle *5.3.2* Core SDLC and DevOps Principles *5.3.3* Programming Testing Methods *5.3.3.1* White-box and Black-box Testing *5.3.3.2* Compile-Time Errors Versus Runtime Errors *5.3.3.3* Input Validation *5.3.3.4* Static and Dynamic Code Analysis *5.3.3.5* Fuzz Testing *5.3.3.6* Programming Vulnerabilities and Attacks *5.3.3.7* Backdoors *5.3.3.8* Memory/Buffer Vulnerabilities *5.3.3.9* Arbitrary Code Execution/Remote Code Execution *5.3.3.10* XSS and XSRF *5.3.3.11* More Code Injection Examples *5.3.3.12* Directory Traversal *5.3.3.13* Zero Day Attack
*5.1.1* General Browser Security Procedures
*5.1.1* General Browser Security Procedures
*5.1* Securing the Browser
*5.1.1* General Browser Security Procedures *5.1.1.1* Implement Policies *5.1.1.2* Train Your Users *5.1.1.3* Use a Proxy and Content Filter *5.1.1.4* Secure Against Malicious Code *5.1.2* Web Browser Concerns and Security Methods *5.1.2.1* Basic Browser Security *5.1.2.2* Cookies *5.1.2.3* LSOs *5.1.2.4* Add-ons *5.1.2.5* Advanced Browser Security
*5.1.1.1* Implement Policies
*5.1.1.1* Implement Policies
*5.1.1.2* Train Your Users
*5.1.1.2* Train Your Users
*5.1.1.3* Use a Proxy and Content Filter
*5.1.1.3* Use a Proxy and Content Filter
*5.1.1.4* Secure Against Malicious Code
*5.1.1.4* Secure Against Malicious Code
*5.1.2* Web Browser Concerns and Security Methods
*5.1.2* Web Browser Concerns and Security Methods
Key Terms *Zero Day Attack*:
A zero-day (aka 0-day) vulnerability is a computer-software vulnerability that is unknown to those who would be interested in mitigating the vulnerability (including the vendor of the target software). Until the vulnerability is mitigated, hackers can exploit it to adversely affect computer programs, data, additional computers or a network. An exploit directed at a zero-day is called a zero-day exploit, or zero-day attack. Day Zero is the day on which the interested party (presumably the vendor of the targeted system) learns of the vulnerability. Until that day, the vulnerability is known as a zero-day vulnerability. An exploitable bug that has been known for thirty days would be called a 30-day vulnerability. Once the vendor learns of the vulnerability, the vendor will usually create patches or advise workarounds to mitigate it. Fewer days since Day Zero means a higher chance no fix has been developed. Even after a fix is developed, the fewer the days since Day Zero, the higher is the probability that an attack against the afflicted software will be successful, because not every user of that software will have applied the fix. For zero-day exploits, the probability that a user has patched their bugs is zero, so the exploit should always succeed. Zero-day attacks are a severe threat.
Explain the concept of an *Exception*:
An *Exception* is an event that occurs during the execution of a program, and requires the execution of code outside the normal flow of control. There are two kinds of exceptions: *# Hardware Exceptions*: Hardware exceptions are initiated by the CPU. They can result from the execution of certain instruction sequences, such as division by zero or an attempt to access an invalid memory address. *# Software Exceptions*: Software exceptions are initiated explicitly by applications or the operating system. For example, the system can detect when an invalid parameter value is specified.
Explain the security concerns associated with authentication cookies:
Authentication cookies are used by web servers to know whether the user is logged in or not, and which account they are logged in with. Without such a mechanism, the site would not know whether to send a page containing sensitive information, or require the user to authenticate themselves by logging in. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by a hacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs (see cross-site scripting [XSS] and cross-site request forgery [XSRF]).
Key Terms *Local Shared Object (LSO)*:
Commonly called a *Flash Cookie*, due to its similarity with an HTTP cookie. A piece of tracking data, created by websites that use Adobe Flash, that may be stored on a user's computer. Local shared objects have been used by all versions of Flash Player since version 6. Flash cookies can be stored or retrieved whenever a user accesses a page containing a Flash application. Flash cookies are a form of local storage. Similar to HTTP cookies, Flash cookies can be used to store user preferences, save data from Flash games, or to track users' Internet activity. LSOs have been criticized as a breach of browser security. There are now browser settings and add-ons to limit the duration of their storage.
How can you configure a Local Group Policy that will apply to your entire organization?
Configure the Group Policy on a central server: *#* Open the Local Group Policy Editor by typing this command in the Run prompt: *gpedit.msc* *#* Navigate to User Configuration > Administrative Templates > Windows Components *Note:* By default, only Internet Explorer and Microsoft Edge are available to be configured in the Local Group Policy Editor. *>>* To modify the security settings for Chrome, download policy_templates.zip from this URL: https://support.google.com/chrome/a/answer/187202?hl=en *>>* To modify the security settings for Firefox, download policy_templates_v1.2.zip from this URL: https://github.com/mozilla/policy-templates/releases *#* To modify maintenance settings, navigate within the Local Group Policy Editor to User Configuration > Windows Settings > [Browser of Choice] Maintenance > Security *#* If you have multiple computers that need to be updated, use a *Template* to quickly modify each of them; or, if you have a *Domain Controller* (central server) configured, make the changes from that location and deploy the changes from it.
How can you determine whether a web communication is *secure* (using HTTPS and either SSL or TLS)?
Each browser has a unique way of confirming this information, but they are all similar: in the left portion of the address bar, a padlock or other small symbol with a green background will appear. By clicking on this symbol, you can inspect the site's *Certificate*, *Cookies*, and *Site Settings* (perhaps other information, depending on the browser).
What is the Windows *Group Policy Management Console (GPMC)*?
GPMC simplifies the management of Group Policy in Windows systems, by making it easier for IT and System Administrators to understand, deploy, manage, troubleshoot Group Policy implementations, as well as automate Group Policy operations via scripting. In Windows Server 2012 R2 and later versions, access GPMC by going to Administrative Tools > Group Policy Management, or by typing *gpmc.msc* in the Run prompt.
Key Terms *Null Pointer Dereference*:
In computer science, a *Pointer* is a programming language object that stores the memory address of another value located in computer memory. A pointer references a location in memory, and obtaining the value stored at that location is known as *dereferencing the pointer*. A *null pointer* is a pointer that is not referencing any object. Because a null pointer does not point to a meaningful object, an attempt to dereference (ie. access the data stored at that memory location) a null pointer usually (but not always) causes a run-time error or immediate program crash.
When closing the web browser, why should you use *Alt*+*F4* instead of the *X* at the top-right of the window?
JavaScript, ActiveX, Flash, and other languages are able to run within the browser, and can be coded to redirect you to a malicious page when clicking the *X*; they can also create a pop-up window that prevents you from leaving the site. *Alt*+*F4* forces the window to close, pre-empting these problems.
Attackers may illegitimately attempt to abuse a proxy server connection as a threat vector. When checking for improper proxy connections in your periodic security audit, what file location should you be sure to check?
The HOSTS file, to ensure an attacker didn't create an account with escalated privileges for themselves. This file is located at: %systemroot%\System32\Drivers\etc
Explain the security risks associated with consolidating several (previously separate) back office systems into a single device:
This setup is more cost-effective, and uses fewer overall CPU resources. However, the more services a device has open, the larger the attack surface becomes. A single device performing the tasks of multiple back office systems will have many more open ports than any of those systems would individually. This introduces a single point of failure into the organization, and increases the threat of that attack.
Explain the security concerns associated with *Tracking Cookies*, and the legislative changes in recent years that have addressed these concerns
Tracking cookies, especially third-party tracking cookies, are commonly used to compile long-term records of individuals' browsing histories - a potential privacy concern that has prompted European and U.S. lawmakers to take action. Currently, European law requires that all websites targeting European Union member states gain "informed consent" from users before storing non-essential cookies on their device.
How do HTTP proxies (proxy servers) work?
When a client queries an HTTP server, the request instead goes to the *HTTP proxy* or *proxy server*. The proxy server forwards that request to the HTTP server, and stores a copy of the requested page in its memory (called *caching*) before forwarding it to the original HTTP client that requested it. All subsequent requests made for that site within a configured window of time will receive the cached copy of the site from the HTTP proxy server. This reduces the traffic load placed on the real HTTP server, and is much faster and more efficient than retrieving a new instance of the same site each time. By also using a content filter, specific website traffic can be filtered out. This increases security for your organization.
When using a web browser, why should you use *incognito mode (private browsing)*?
When you browse privately, other people who use the device won't see your activity. The browser doesn't save your browsing history or information entered in forms. Cookies (trackers) and site data are remembered while you're browsing, but deleted when you exit Incognito mode. Private browsing offers three advantages: *# Privacy*: Browsing the Internet in incognito mode can help protect your privacy, especially when you're using a shared computer. Websites you visit in an incognito window aren't saved in the browser history. *# Security*: Cookies created during an incognito browsing session are automatically deleted when the window is closed, making it ideal if you're concerned about the security of your personal or business accounts, and especially valuable when using shared or public computers. Even if you forget to sign out of a service, the sign-in cookie will be deleted when you close an incognito window, preventing anyone from accessing your account. *# Multiple Sessions*: Because cookies aren't shared between normal and incognito windows in Chrome, you can use the incognito window to log in to a second account on a single device without logging out of the first one. For example, you could open an incognito window and log in to your work Gmail account while still logged into your personal account in a normal window. Similarly, if a friend comes to visit and wants to quickly check his Facebook account, you can open an incognito window for him to use so you don't have to log out of your own account.
Key Terms *Cross-Site Scripting (XSS)*:
a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. Bug bounty company HackerOne in 2017 reported that XSS is still a major threat vector. XSS effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner.
Key Terms *White-Box Testing*:
aka *Clear Box Testing*, *Glass Box Testing*, *Transparent Box Testing*, and *Structural Testing A method of testing software that tests internal structures or workings of an application, instead of its functionality, as is done with Black-Box Testing*. An internal system perspective is used to design test cases. The tester chooses inputs to exercise paths through the code and determine the expected outputs. White-box testing can be applied at the unit, integration and system levels of the software testing process. It tests paths within a unit, paths between units during integration, and between subsystems during a system-level test. Though this method of test design can uncover many errors or problems, it has the potential to miss unimplemented parts of the specification, or missing requirements.
Key Terms *Cross-Site Request Forgery (XSRF)*:
also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF. a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
Key Terms *Buffer Overflow*:
an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory locations. *Buffers* are areas of memory set aside to hold data as it is moved from one section of a program to another, or between programs. Buffer overflows are triggered by malformed inputs. If one *assumes* that inputs will be smaller than the size of the buffer, transactions that produce data larger than the size of the buffer will will cause the buffer to overflow, causing errors and unintended effects. By sending in data designed to cause a buffer overflow, it is possible to replace legitimate code with malicious code, or selectively overwrite data pertaining to the program's state. Programming languages commonly associated with buffer overflows include C and C++. *Bounds Checking*, *Canary Values*, and *Address Space Memory Randomization (ASMR)* can prevent buffer overflows.
Key Terms *Integer Overflow*:
an event that occurs when an arithmetic operation attempts to create a numeric value outside the range that can be represented with a given number of digits - either larger than the maximum or lower than the minimum value. The most common result of an overflow is that the least significant digits of the result are stored; the result is said to wrap around the maximum (i.e. modulo a power of the radix, usually two in modern computers, but sometimes ten or another radix). An overflow condition may give results leading to unintended behavior, especially if the possibility has not been anticipated.
Explain the concept of *Vectored Exception Handling*:
an extension to structured exception handling. An application can register a function to watch or handle all exceptions for the application. Vectored handlers are not frame-based, therefore, you can add a handler that will be called regardless of where you are in a call frame. Vectored handlers are called in the order that they were added, after the debugger gets a first chance notification, but before the system begins unwinding the stack.
Key Terms *Secure Coding Concepts*:
the practice of developing computer software in a way that guards against the accidental introduction of security vulnerabilities. Defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities.
Key Terms *Secure Code Review*:
the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. Code review is a way of ensuring that the application has been developed so as to be "self-defending" in its given environment. Security code review is a method of assuring secure application developers are following secure development techniques. A general rule of thumb is that a penetration test should not discover any additional application vulnerabilities relating to the developed code after the application has undergone a proper security code review.
Key Terms *Input Validation*:
the proper testing of any input supplied by a user or application. This prevents improperly formed data from entering an information system.