Kingfisher Security+ SYO-501 Chapter 5: Application Security
Browser & App Security Opening Statements
*Browser security should be at the top of any security admin's list, due to its inherent insecurity "out of the box." Most browsers have built-in options that you can enable to make them more secure,and third-party programs can help in this endeavor as well. *Office applications, back office applications (such as the command line, and those that supply database info and email) are also vulnerable and should be hardened accordingly. And finally, any applications being developed within your domain should be reviewed carefully as well. Be sure to secure any app used or developed on your network.
Importance of Programming Knowledge as a Security Admin
*Gain a basic knowledge of programming languages (Visual Basic, C++, C#, Java, and Python) as well as web-based programming languages (HTML, ASP, and PHP), plus knowledge of database programming languages such as SQL to help you as a security admin acting as a liaison to the programming team, or if you're involved in actually testing an application.
General Browser Security Procedures
*General procedures, regardless of browser type or desktop/mobile differences are: Implement policies Train your users Use a proxy and content filter Secure against malicious code
Use a Proxy and Content Filter
*HTTP proxies (known as proxy servers) act as a go-between for the clients on the network and the Internet. They cache website info for the clients, reducing the amount of requests that need to be forwarded to the actual corresponding web server on the Internet. This saves time, makes more efficient use of the bandwidth, and helps secure the client connections. By using a content filter in combination with this, specific websites can be filtered out, especially malicious ones or ones that can be a waste of man-hours. *To connect to a proxy server with a browser you can either have the browser automatically detect the proxy (which is more common) or you can configure it statically. Here's how: Open IE On the menu bar go to Tools. If the menu isn't visible, press ALT+T Select Internet Options. This should display the associated dialog box. Click the Connections tab. Click the LAN Settings button. This displays the Local Area Network (LAN) Settings window. Check the Use a Proxy Server for Your LAN checkbox. This enable the fields in the Proxy Server area. In the Address field, type in the IP address or name of the proxy server (ex. 192.168.1.250) Select a port; by default 80 is selected because it corresponds with HTTP and most web requests. However, your proxy might use a different port. Consult your network documentation for details. If your proxy server also acts as a go-between for other services such as FTP or secure web transactions, configure these by clicking the Advanced button. Click OK for the Local Area Network (LAN) Settings in the dialog box. Click OK for the Internet Options dialog box. The client should now be configured to use a proxy server for all its HTTP transactions. To remove the proxy server at any time, simply deselect the Use a Proxy Server for Your LAN checkbox. *This setting can also be configured within an organizational unit's Group Policy object on the domain controller. This way, it can be configured one time to affect all the computers within the particular OU (Organizational Unit). *Proxies can also be used by an attacker to send clients to websites of the attacker's choice by changing the proxy configuration on the client's operating system. Security admins should know how to enable a legitimate proxy connection used by their organization, but also know how to disable an illegitimate proxy connection used by attackers.
Securing the Browser
*Internet Explorer, Firefox and Chrome are the three most popular web browsers in the business world. As a security admin, plan for performance and security when picking a standard web browser for the whole office. Some recommendations though: Do not use the latest version of a browser. Give it some time for possible issues, backdoors and whatever else to show up. For a business, the browser needs to be rock-solid, and they will not tolerate any downtime. Allow 6-12 months before embracing new software. Next, consider what type of computer/s will be running the browser. Linux computers don't run Internet Explorer, so Firefox or Chrome would be preferred (though there are ways to run IE on Linux, but WINE (which allows Windows apps to be run on Linux) must be installed). Another point is whether you'll be centrally managing multiple client computers' browsers. IE can be centrally managed through the use of Group Policy objects (GPOs) on a domain. Also consider how the browser companies fix vulnerabilities. Vulnerabilities in Firefox become common knowledge quickly, which could lead to rapid exploits of the vulnerability before Mozilla can fix it, though they usually fix things faster than IE. On the other hand, Microsoft will find out about exploits but attempt to keep them secret, so less people may discover the exploit but fixing it will take longer. Some websites require IE for browsing while others perform poorly on IE. In terms of security, IE and Firefox are evenly matched today.
Implement Policies
*Policies can be hand-written, configured at the browser, implemented within the computer OS, or configured on a server centrally. They can also be configured to manage add-ons, and disallow access to websites known to have malicious content, have Flash content, or use a lot of bandwidth. *User Configuration > Administrative Templates > Windows Components > Internet Explorer > Security Features (For accessing the security features within the local group policy of a Windows 7 computer) *User Configuration > Windows Settings > Internet Explorer Maintenance > Security (To modify IE maintenance security) *Don't configure these policy settings on many more than a few computers individually (so as not to waste time). If you have multiple computers that need IE security policy updates, consider using a template or if you have a domain controller consider making the changes from that central location. From there, much more in-depth security can be configured and deployed to the IE browsers within multiple computers.
Secure Against Malicious Code
*Security admins might need to configure a higher level of security concerning ActiveX controls, Java, JavaScript, Flash media, phishing, etc.
Securing Internet Explorer
*The more a browser is secured, the less functional it becomes. Update the browser (IE can be updated directly through Windows Update; however, watch for completely new versions as well (which can be downloaded from Microsoft's website as well). When updating, always check the list of updates before installing them. Install pop-up blocking and other ad-blocking solutions. Many antivirus suites have pop-up blocking tools. Google Toolbar and others like it are another option. Newer versions of browsers can also block some pop-ups on their own. Configure security within the browser itself. By adjusting IE settings, you can prevent some spyware and other malicious attacks. First we configure security zones, which can be completed on the Internet Options dialog box (accessed by going to Tools on the menu bar and selecting Internet Options). Then click the Security tab to show the Internet Explorer security zones. Adjust the security level for the zone named Internet. Many organizations set this to "High." You can set the security level in the same manner for the Local Intranet zone, Trusted Sites zone, and Restricted Sites zone. You can also use the Custom Level button to disable ActiveX controls and plug-ins, turn the scripting of Java applets on and off, etc. The Security tab is also where you can add trusted sites to the computer. Cookies can also pose a security threat. The Privacy tab in the Internet Options window determines how cookies are handled. Cookies: Text files placed on the client computer that store info about it, which could include browser history and possibly user credentials. The latter are sometimes referred to as "persistent cookies," used so that a person doesn't have to log in to a website every time. *Also consider checking the Never Allow Websites to Request Your Physical Location box. Another smart security precaution. You can override any automatic cookie handling that might occur by clicking the Advanced button (which displays the Advanced Privacy Settings dialog box), checking the box and selecting Prompt, which means the user will always be prompted when a website attempts to create a cookie. *In some cases an organization deals with too many websites with too many cookies, so this particular security configuration isn't an option. Tracking cookies are used by spyware to collect info about a user's activities. Cookies can also be the target for various attacks; namely, session cookies are used when an attacker attempts to hijack a session. There are several types of session hijacking. One common type is cross-site scripting (XSS), which is when the attacker manipulates a client's computer into executing code considered trusted as if it came from the server the client was connected to. The hacker can then acquire the client computer's session cookie (allowing them to steal sensitive info) or exploit the computer in other ways. Locally Shared Objects (LSOs or Flash Cookies): Data that Adobe Flash-based websites store on users' computers, especially for Flash games. LSOs are used by a variety of websites to collect info about users' browsing habits. However, LSOs can be disabled via the Local Settings Manager (in most of today's operating systems) or, for older OSes, via the Online Settings Manager at Adobe's website. LSOs can also be deleted entirely with third-party software, or by accessing the user's profile folder in Windows. IE's Content tab allows for parental controls and a content advisor. This tab is also where you can find encryption certificates. The Connections tab enables a user to make secure connections through a VPN (Virtual Private Network) and also connect to the Internet via a proxy server. The Advanced Tab has more than a dozen security settings (found by scrolling toward the bottom of the Settings box). Organizations use this tab to erase browser history whenever a guest closes the browser, and remote users/employees should be trained to delete temporary files and cookies when using computers on the road. In this tab, you can also configure to check if TLS/SSL certificates of sites have been revoked. You can also check if the proper version of TLS or SSL is used. You can enable and disable add-on programs in the Programs tab by clicking the Manage Add-ons button (only accessed directly within the Tools menu). ActiveX controls are small program building blocks used to allow a web browser to execute a program. They're similar to Java applets; however, Java applets can run on any platform, but ActiveX only runs on IE and Windows OSes. These can possibly contain viruses, spyware, or worse. These are known as malicious add-ons. Flash scripts especially can be a security threat. You can disable undesirable scripts on the Advanced tab or the Custom level of the Security tab. *Removing web browsers can be difficult, if not downright impossible, and should be avoided. Web browsers become one with the OS, especially when it comes to IE and Windows.
Systems Development Life Cycle
*To develop a secure application, the developer has to scrutinize it at every turn, and from every angle, throughout the life of the project. Systems Development Life Cycle (SDLC): An organized process of planning, developing, testing, deploying, and maintaining systems and applications, and the various methodologies used to do so. The SDLC can be broken down into several phases: Planning and Analysis: Goals are determined, needs are assessed, and high level planning is accomplished. Systems Design: The design of the system or application is defined and diagramed in detail. Implementation: The code for the project is written. Testing: The system or application is checked thoroughly in a testing environment. Deployment: The system or application is put into production and is now available to end-users. Maintenance: Software is monitored and updated throughout the rest of its life cycle. *A programmer/developer should keep the CIA concept in mind: Maintaining Confidentiality: Only allowing users access to data to which they have permission. Preserving Integrity: Ensuring data is not tampered with or altered. Protecting availability: Ensuring systems and data are accessible to authorized users when necessary. Secure Code Review: An in-depth code inspection procedure, often included by organizations as part of the testing phase of the SDLC but usually conducted before other tests such as fuzzing or penetration tests. Threat Modeling: Enables you to prioritize threats to an application, based on their potential impact. The modeling process includes identifying assets to the system or application, uncovering vulnerabilities, identifying threats, documenting threats, and rating those threats according to their potential impact. Threat modeling is often incorporated into the SDLC during the design, testing, and deployment phases. *Other security principles that should be incorporated into the SDLC include: Principle of Least Privilege: Apps should be coded and run in such a way as to maintain the principle of least privilege. Users should only have access to what they need. Processes should run with only the bare minimum access needed to complete their functions. However, this can be coupled with separation of privilege, where access to objects depends on more than one condition (ex. Authentication plus an encrypted key). Principle of Defense in Depth: The more security controls the better. The layering of defense in secure coding may take the form of validation, auditing, special authentication techniques, and so on. Applications Should Never Trust User Input: Input should be validated carefully. Minimize the Attack Surface Area: Every additional feature a programmer adds to an app increases the size of the attack surface and increases risk. Unnecessary functions should be removed, and necessary functions should require authorization. Establish Secure Defaults: Out-of-the-box offerings should be as secure as possible. If possible, user password complexity and password aging default policies should be configured by the programmer, not the user. Permissions should default to no access and should be granted only as they are needed.d Fail Securely: At times, apps will fail. How they fail determines their security. Failure exceptions might show the programming language used to build the app, or worse, lead to access holes. Error handling/exception handling code should be checked thoroughly so that a malicious user can't find out any additional info about the system. These error handling methods are sometimes referred to technically as pseudocodes. Fix Security Issues Correctly: Once found, security vulnerabilities should be thoroughly tested, documented, and understood. Patches should be developed to fix the problem, but not cause other issues or application regression. *For the Security+ exam, the most important parts of the SDLC are maintenance and testing. In the maintenance phase, which doesn't end until the software is removed from all computers, an app needs to be updated accordingly, corrected when it fails, and constantly monitored. In the testing phase, a programmer (or a team of programmers and other employees) checks for bugs and errors in a variety of ways. The best way to prevent attacks and vulnerabilities to a system or app is to test and review code.
Train Your Users
*User training is important to determine which websites to access, how to use search engines, and what to do if pop-ups appear on the screen. Onsite training classes, webinars, and downloadable screencasts all work great. Or consider writing a web article to this effect. For example, explain the value of pressing ALT+F4 to close pop-ups instead of clicking on them. *If your browser shows a padlock next to the URL in order to convey that a website is secure and trustworthy, click on the padlock and click More Information or Connection (depending on the browser) to see what kind of encryption they're using and what certificate is being used.
Securing Other Applications
*Users shouldn't have access to any apps other than the ones they need. User Account Control (UAC): A security component of Windows Vista and newer, as well as Windows Server 2008 and newer, that keeps every user (besides the actual admin account) in standard user mode instead of as an admin with full administrative rights--even if they're a member of the administrators group. It's meant to prevent unauthorized access and avoid user error in the form of accidental changes. *Another way to deny access to apps is to create a policy. On a Windows Server you can do this two ways: Disallow access to specific apps; this policy is called Don't Run Specified Windows Applications (a form of application blacklisting). Configure the Run Only Specified Windows Applications policy (a form of application whitelisting). In general, apps should be updated, patched, or have the appropriate service packs installed. This is collectively known as application patch management, and is an overall part of the configuration management of an organization's software environment. *Common Applications and Safeguards: Outlook: Install the latest Office service pack (applies to all Office suite apps) Keep Office up to date with Windows Update (also applies to all Office suite apps) Consider upgrading to a new version of Office, if the one you're using is no longer supported. Increase the junk email 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. Consider encrypting the authentication scheme, and possibly other traffic, including message traffic between Outlook clients and Exchange servers. Secure Password Authentication (SPA) can be used to secure the login, and S/MIME and PGP can be used to secure actual email transmissions. Or, in the case of web-based email, 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. *Mobile apps might need GPS disabled to protect them and the mobile device in general. Also, use strong passwords for email accounts and account to app stores and similar shopping portals. Watch for security updates for the mobile apps your organization uses. *Back office applications that run on servers (database software, email server software, etc.) need to be hardened and secured as well. (ex. Microsoft SQL Server and Exchange Server, FTP servers and web servers) *FTP servers, database servers and other similar servers will have their own separate admin account with a blank password by default. The names of these admin user accounts are common knowledge and if they haven't been secured then they're easy pickings. Be sure to rename accounts (and disable unnecessary accounts) and configure strong passwords. *Also watch out for consolidation. Many organizations will merge several back office systems onto one computer to save money. Unfortunately, the more services a server has running, the more open doorways that exist to that system and the more possible ways that the server can fail. The most important services should be compartmentalized physically or virtually in order to reduce the size of the attack surface, and lower the total amount of threats to an individual system. *Always test what effects one new piece of software will have on the rest of your installed software before implementation.
Fuzz Testing/Fuzzing
A concept where random data is inputted into a computer program in an attempt to find vulnerabilities. This is often done without knowledge of the source code of the program. The program to be tested is run, has data inputted to it, and is monitored for exceptions such as crashes. This can be done with apps and OSes. It's commonly used to check file parsers within apps such as Microsoft Word, and network parsers that are used by protocols such as DHCP. Fuzz testing can uncover full system failures, memory leaks, and error-handling issues. Fuzzing is usually automated (a program that checks a program) and can be as simple as sending a random set of bits to be inputted in the software. Designing those bits can be tricky, and it often takes a myriad of variations of code to find vulnerabilities. Once the fuzz test is done, the results are analyzed, the code is reviewed and made stronger, and vulnerabilities that were found are removed. The stronger the fuzz test, the better the chances that the program will not be susceptible to exploits. *Once code is properly tested and approved, it should be reused whenever possible. This helps to avoid "re-creating the wheel" and avoids common mistakes that others might have fixed.
Directory Traversal (or the ../ (dot dot slash) Attack
A method of accessing unauthorized parent (or worse, root) directories. Often used on web servers that have PHP files and are Linux or UNIX-based, but can also be perpetrated on Microsoft OSes (in which case it would be the "..\ (dot dot backslash) attack). Designed to get access to files such as ones that contain passwords. This can be prevented by updating the OS, or by checking the code of files for vulnerabilities, otherwise known as fuzzing. Example: A PHP file on a Linux-based web server might have a vulnerable "if" or "include" statement, which when attacked properly could give the attacker access to higher directories and the password file.
Input/Data Validation
A process that ensures the correct usage of data--it checks the data that is inputted by users into web forms and other similar web elements. If data is not validated correctly, it can lead to various security vulnerabilities and the possibility of data corruption. You can validate data in many ways, from coded data checks and consistency checks to spelling and grammar checks, etc. All data should be checked to make sure it's being entered correctly and won't create or take advantage of a security flaw. Should be done both on the client side and on the server side. (ex. Using approved characters to create a username or email address) Input validation is the key to preventing attacks such as SQL injection and XSS. All form fields should be tested for good input validation code, both on the client side and server side. By combining the two, and checking every access attempt, you develop complete mediation of requests.
White Box Testing (or Transparent Testing)
A way of testing the internal workings of the application or system. Testers must have programming knowledge and are given detailed information about the design of the system. They're given login details, production documentation, and source code. System testers might use a combination of fuzzing, data flow testing, and other techniques such as penetration testing and sandboxes. Penetration Test: Method of evaluating a system's security by simulating one or more attacks on that system. Sandbox: When a web script (or other code) runs in its own environment for the express purpose of not interfering with other processes, often for testing. Sandboxing technology is frequently used to test unverified apps for malware, malignant code, and possible errors such as buffer overflows.
Securing Other Browsers
Advanced Settings in Chrome allow you to configure privacy settings, like changing the content settings (turn off JavaScript, block third-party cookies, etc.), disallow tracking when browsing the web, or send usage statistics to Google. Chrome uses a very similar proxy connection option to IE (in the Network section of Chrome), piggybacking off of IE (what is configured in IE is configured in Chrome. So even if Chrome is updated, you have to make sure that IE is updated too. Apple's Safari browser, as well as OS X, can be the victim of viruses, ransomware, and lots of other malware. Safari > Preferences > Security to access Safari's security options. By default, plug-ins are allowed, and JavaScript is enabled. Disabling these two is one way to help secure the browser (it is recommended that you remove Java from the system altogether. When Mac users browse the web, it's smart to limit the users to downloading apps from the App Store only. Also patch the system and run AV software. When it comes to browsers such as Opera and others, they can all benefit from the same basic methods used for IE and Firefox. Mobile devices can also be configured for security (cookies, location access, password storage, etc.) When it comes to mobile devices, also avoid rooting or jailbreaking the device, which makes it easier for attackers to assault the web browser and, ultimately, subjugate the system. Periodically review your security policies for web browsing and keep up to date with the latest browser functionality, updates, security settings, and malicious attacks. Sometimes a higher level of security can cause a browser to fail to connect to some websites. If a user can't connect, check the various security settings and, if necessary, reduce the security level temporarily.
Backdoors
Apps should be analyzed for backdoors, which are used in computer programs to bypass normal authentication and other security mechanisms in place. These can be avoided by updating the operating system and applications and firmware on devices, and especially by carefully checking the code of the program. If the system isn't updated, a malicious person could take all kinds of actions via the backdoor. (ex. Disgruntled software developers can install a backdoor that reactivates a user account after it's disabled through the use of a logic bomb inserted through the backdoor). In summary, make sure the OS is updated and consider job rotation, where programmers check each other's work.
Summary of Programming Vulnerabilities and Attacks
Backdoor: Placed by programmers, knowingly or inadvertently, to bypass normal authentication, and other security mechanisms in place. Buffer Overflow: When a process stores data outside the memory that the developer intended. Remote Code Execution (RCE): When an attacker obtains control of a target computer through some sort of vulnerability, gaining power to execute commands on that remote computer. Cross-Site Scripting (XSS): Exploits the user's browser's trust in a website through code injection, often in web forms. Cross-Site Request Forgery (XSRF or CSRF): Exploits the trust a website has in a user's browser, which becomes compromised and transmits unauthorized commands to the website. Code Injection: When user input in database web forms is not filtered correctly and is executed improperly. SQL injection is a very common example. Directory Traversal: A method of accessing unauthorized parent (or worse, root) directories. Zero Day Attacks: A group of attacks executed on vulnerabilities in software before those vulnerabilities are known to the creator.
Securing FireFox
By setting one browser as the default over the other, you can avoid problems associated with users clicking links within applications such as email, possibly opening the wrong browser automatically. Firefox has an option for a Warn Me When Websites Try to Redirect or Reload the Page checkbox in the General tab of the Advanced options. The Options dialog box is where all the important security configurations appear in Firefox. Firefox does not offer security zones like IE, nor does it offer features for management of ActiveX controls. Cookies can be configured by clicking the Privacy option at the top of the Options dialog box and selecting Use Custom Settings for History from the drop-down menu. By default, third-party cookies are always accepted. Allowed cookies are known as whitelists. The Security option houses configurations such as add-on warnings, password remembrance, and other warning messages. You have the option of setting a "Master Password" that allows you to access all the passwords you use after entering the Master Password at Firefox's request. The Advanced option lets you access the Certificates tab, the Network tab (for connecting to the internet via a proxy server). Connecting to a proxy with Firefox is done by: Click Settings, displaying the Connection Settings dialog box. Proxies can be auto-detected, but to continue setting up one manually, use the Manual Proxy Configuration radio button. Type in the IP address or name of the proxy server, followed by the inbound port it uses. Firefox also has the option of extensions or "add-ons." One example of an add-on is Adblock Plus, which updates automatically to deal with new types of advertisement pop-ups. One smart add-on is NoScript. It protects against malicious JavaScript, Flash, and XSS code. This helps to ward off hijacking, click-jacking, and cross-site scripting (XSS) attempts.
Injection Attacks in Databases that Use SQL
Databases are just as vulnerable as servers. The most common type is the relational database, administered by a Relational Database Management System (RDBMS) which is usually written in the Structured Query Language (SQL). The main concern with SQL is the SQL injection attack (occurs in databases, ASP.NET apps, and blogging software (ex. WordPress) that use MySQL as a back end. In these attacks, user input in web forms isn't filtered correctly and is executed impropery, with the end result of gaining access to resources or changing data. Example: Login for a web page using SQL back end (ie. WordPress) can be insecure. An attacker will attempt to access the database (from a form, or in a variety of other ways), query the database, find out a user, and then inject code to the password portion of the SQL code (maybe something as simple as x = x) which will allow any password for the user account to be used. If the login script was written properly (and validated properly), it should deflect this injected code. You can defend against this by constraining user input, filtering user input, using input validating forms, and using special parameters with stored procedures.
Injection Attacks in NoSQL Databases
Databases that don't use SQL (known as NoSQL databases; commonly found in virtual systems provided by cloud-based services) offer a different mechanism for retrieving data. However, there are also NoSQL injection attacks as well, and because of the type of programming used in them, it can potentially have a greater impact than a SQL injection attack. Example: JavaScript Object Notation (JSON) Attack: NoSQL databases are also vulnerable to brute force attacks (cracking passwords) and connection pollution (combo of XSS and code injection techniques). Methods to defend against NoSQL attacks are similar to those used to defend against SQL attacks. Unfortunately, since NoSQL databases are often used within cloud services, a security admin might not have much control over the level of security it implements. In these cases, careful scrutiny of the service-level agreement (SLA) between the company and the cloud provider is imperative.
Zero Day Attack
Executed on a vulnerability in software, before the creator knows about that vulnerability. Not a specific attack, but rather a group of attacks including viruses, Trojans, buffer overflow attacks, and so on. These attacks can cause damage even after the creator knowns of the vulnerability, because it may take time to release a patch to prevent the attacks and fix damage caused by them. It can be discovered through thorough analysis and fuzz testing. Zero day attacks can be prevented by using newer OSes that have protection mechanisms and by updating those OSes. It can also be prevented by using multiple layers of firewalls and by using whitelisting, which only allows known good apps to run. Collectively, these preventative methods are known as zero day protection.
XSRF or CSRF (Cross Site Request Forgery) or One-Click Attack
Exploits the trust that a website has in a user's browser (as opposed to the XSS attack exploiting the trust that a user's browser has in a website). The user's browser is compromised and transmits unauthorized commands to the website. Chances of this attack can be reduced by by requiring tokens on web pages that contain forms, special authentication techniques (possibly encrypted), scanning XML files (which could contain the codes required for unauthorized access), and submitting cookies twice instead of once, while verifying that both cookie submissions match.
Arbitrary Code Execution Exploits
Programs that are designed to exploit software bugs or other vulnerabilities. These types of exploits inject "shellcode" to allow the attacker to run arbitrary commands on the remote computer. This type of attack is also known as remote code execution (RCE) and can potentially allow an attacker to take full control of the remote computer, turning it into a zombie (to be used in a botnet). RCE commands can be sent to the target computer using the URL of a browser, or by using the Netcat service, among other methods. To defend from this, apps should be updated, or if the app is being developed by your organization, it should be checked with fuzz testing and strong input validation (client side and server side) as part of the testing stage of the SDLC. If you have PHP running on a web server, it can be set to disable remote execution of configurations. A web server (or other server) can also be configured to block access from specific hosts. *RCE is also very common with web browsers. All browsers have been affected at some point, though some instances were more publicized than others. For proof, Google search "Common Vulnerabilities and Exposures (CVE) for each web browser.
Secure Programming
Secure Programming or Secure Coding Concepts: The best practices used during software development in an effort to increase the security of the application being built. They harden the code of the application.
LDAP (Lightweight Directory Access Protocol) Injection
Similar to SQL injection, again using a web form input box to gain access, or by exploiting weak LDAP lookup configurations. The Lightweight Directory Access Protocol is used to maintain a directory of information such as user accounts, or other types of objects. The best way to protect against this (and all code injection techniques for that matter) is to incorporate strong input validation.
Gray Box Testing
The tester has internal knowledge of the system from which to create tests but conducts the tests the way a black-box tester would--at the user level.
Black Box Testing
Utilizes people who don't know the system. These people (or programs, if automated) test the functionality of the system. Specific knowledge of the system code, and programming knowledge in general, is not required. The tester doesn't know about the system's internal structure and is often given limited info about what the application or system is supposed to do. In black-box testing, one of the most common goals is to crash the program. If a user is able to crash the program by entering improper input, the programmer has probably neglected to thoroughly check the error-handling code and/or input validation.
XSS (Cross Site Scripting)
Vulnerabilities that can be exploited with a type of code injection (exploitation of a computer programming bug or flaw by inserting and processing invalid info, used to change how the program executes data). Example: An attacker inserts malicious scripts into a web page in the hopes of gaining elevated privileges and access to session cookies and other info stored by the user's web browser. This code (often JavaScript) is usually injected from a separate "attack site." It can also manifest as an embedded JavaScript image tag, header manipulation (as in manipulated HTTP response headers), or other HTML embedded image object within emails (that aren't web-based). XSS attacks can be defeated by programmers through output encoding (JavaScript escaping, CSS escaping, and URL encoding), by preventing the use of HTML tags, and by input validation: ex. Checking forms and confirming that input from users does not contain hypertext. Users can decrease the possibility of the attack by increasing cookie security and by disabling scripts. If XSS attacks by email are a concern, the user could opt to set his email client to text only.
Buffer Overflows
When a process stores data outside the memory that the developer intended. This could cause erratic behavior in the application, especially if the memory already had other data in it. Stacks and heaps are data structures that can be affected by buffer overflows. The stack is a key data structure necessary for the exchange of data between procedures. The heap contains data items whose size can be altered during execution. Value types are stored in a stack, while reference types are stored in a heap. An ethical coder will try to keep these running efficiently. An unethical coder wanting to create program vulnerability could, for example, omit input validation, which could allow a buffer overflow to affect heaps and stacks, which in turn could adversely affect the application or the OS in question. Example: A programmer allows for 16 bytes in a string variable but doesn't set the limit for bytes copied over to the string variable at 16 bytes ("no more than 16 bytes can be copied over to the string variable"). An attacker can corrupt the stack with no-operation (no-op, NOP, or NOOP) machine instructions, which can start an NOP slide when used in large numbers, which can lead to execution of unwanted arbitrary code or a denial-of-service on the target computer. This can be prevented by patching the system or app, making sure the OS uses data execution prevention, and using bounds checking (programmatic method of detecting whether a variable is within design bounds before it's allowed to be used). It can also be prevented by using correct code, checking code carefully, and using the right programming language for the job in question (special values called "canaries" are used to protect against buffer overflows; ie. Canary in a coal mine).
Arbitrary Code Execution
When an attacker obtains control of a target computer through some sort of vulnerability, thus gaining the power to execute commands on that remote computer at will.
Integer Overflows
When arithmetic operations attempt to create a numeric value too big for the available memory space. This creates a "wrap" and can cause resets and undefined behavior in programming languages such as C and C++. The security ramification is that the integer overflow can violate the program's default behavior and possibly lead to a buffer overflow. This can be prevented or avoided by making overflows trigger an exception condition, or by using a model for automatically eliminating integer overflow, such as the CERT As-if Infinitely Ranged (AIR) integer model.
DLL (Dynamic Link Library) Injection Attack
When code is run within the address space of another process by forcing it to load a dynamic link library (DLL). Ultimately, this can influence the behavior of a program that was not originally intended. It can be uncovered through penetration testing. *The best way to defend against code/command injection techniques in general is by implementing input validation during the development, testing, and maintenance phases of the SDLC.
XML Injection Attacks
XML injection attacks can compromise the logic of XML (Extensible Markup Language) apps. Example: XML structures that contain code for users can be used to create new users and possibly obtain administrative access. This can be tested for by attempting to insert XML metacharacters such as single and double quotes. It can be prevented by filtering in allowed characters (ex. A-Z only). This is an example of "default deny" where only what you explicitly filter in is permitted; everything else is forbidden. *When attackers utilize code injecting techniques, they're adding their own code to existing code, or are inserting their own code into a form. A variant of this is command injection, which doesn't use new code; instead, an attacker executes system-level commands on a vulnerable app or OS. The attacker might enter the command (and other syntax) into an HTML form or other web-based form to gain access to a web server's password files.