CompTIA Security+ SYO-401

Certification Training
9954 Learners
View Course Now!
33 Chapters +

Importance of Application Security Controls and Techniques Tutorial

1 Explaining the Importance of Application Security Controls and Techniques

Applications in a corporate network need to have smart programming to keep unauthorized access at bay. No amount of user training, auditing, or network security tools can compensate for bad programming. Solid security of the applications in use is indispensable for long-term survival of any organization. Application security commences with safe coding and design techniques that you can sustain via testing and patching over the software’s lifespan. In this lesson, we will explore a few application security controls and techniques. The following screen explains the objectives covered in this lesson. After completing this lesson, you will be able to: • Explain fuzzing, • Describe secure coding concepts, • Identify prevention techniques for cross-site scripting and cross-site request forgery , • Explain the importance of application hardening, application patch management, and configuration baselining, • Distinguish between NoSQL and SQL databases, and • Distinguish between server-side and client-side validation.

2 Fuzzing as Application Security Technique

In this topic, you will learn about fuzzing as a technique for application security. We can implement application security through a set of controls and techniques applicable to a software program or application. This set of controls and techniques, at times, is also applicable to the application’s dependencies throughout its life cycle, right from design to deployment. For example, scanning and validating inputs are some techniques for application security used throughout the life cycle of application development. These controls and techniques aim to make the applications less vulnerable to threats. Because an application processes or stores data, one cannot deny the importance of securing it. In fact, application security is as essential as network security and operating system security, although it is practically an overlooked aspect of overall organizational security. For applying the most effective security controls, we need to understand how hackers compromise devices and systems via applications running on them. One of these ways of compromising the systems is to input values to an application, resulting in system failures or crashes. Ideally, we can prevent this with the help of fuzzing, which we will explore in the next screen. Applications usually require input in the form of specific data types such as string values, numbers, or a mix of both. Chances are always there for users to submit an unexpected input value or type, which results in abnormal application behavior such as crash or denial of service. At this point, users may obtain elevated privileges or access to data they should not have. For catching all possible unexpected values, we can implement fuzzing by using a fuzzer, also known as the fuzz-testing tool. Fuzzing refers to the testing method where we submit unexpected values as input to an application in an automatic way to find application flaws. These values can be invalid, random, or just unexpected to make a system to crash or fail. A common method of fuzzing is to flood the input stream with random bits. Once a fuzz tool discovers a value causing an abnormal application behavior, we document both the input value and abnormal response for reviewing and fixing the application. In this way, fuzzing helps exploit vulnerabilities in coding by validating the input. It is the responsibility of the programmer to implement secure coding practices to ensure application security, and this is what we will explore next.

3 Secure Coding Concepts for Application Security

In this topic, you will learn about secure coding cIt is true that software programmers can code in different ways for obtaining the same desired output while designing an application. However, when we do secure coding, we write the code in such a manner that it gives the output in a secured way. In simple words, secure coding gives full control to the programmer regarding the way in which the code runs as well as the manner in which the application responds to an input. Examples of secure coding are writing smart exception-handling routines and validating all input values or data submitted to the application. Handling exceptions means catching hold of any unwanted response or output of code, if any, and directing the execution of the application to an alternate flow instead of closing or crashing the application. For example, if an application attempts to divide a number by zero, which is practically infeasible, a proper message is displayed instead of turning off the application abruptly. Similarly, validating input values involves checking the format and length of all values in the fields entered by the user. Both these examples ensure that you only get what you want. Secure coding standards and best practices are available at Open Web Application Security Project, or OWASP, an esteemed software security community dedicated to application security. oncepts to ensure application security.

4 Cross-site Scripting Prevention for Application Security

There are several ways to prevent a cross-site scripting attack. Measures to prevent a cross-site scripting attack include hardened Web server, application firewall, and input validation at the server side and client side. As a user on the Web, you can get rid of such attacks by patching your system, configuring your browser properly, keeping an anti-virus updated, and running it all the time, avoiding non-mainstream sites, and using a script-protection tool such as NoScript. For a programmer, the most effective ways to keep a cross-site scripting attack on a resource host at bay are validating input, rejecting any input appearing as a script, getting rid of meta characters, and coding protectively. Before we move ahead, let us just explore the differences between client-side and server-side validation.

5 Cross-site Request Forgery Prevention for Application Security

In this topic, you will learn about preventing a cross-site request forgery attack for ensuring application security. Cross-Site Request Forgery, also called C-S-R-F and pronounced sea-surf or X-S-R-F, refers to a one-click attack or a session riding attack. It is a kind of malicious act where the attack focuses on the user’s browser instead of the Web site or application being visited unlike cross-site scripting. CSRF aims to trick the user or the browser into performing unauthorized or unintended actions on behalf of the user. The attacker sends unauthorized commands from the user’s browser by taking the advantage of the trust formed between the Web site and the authorized user by using the user’s valid browser cookies. This means the sites most vulnerable to such an attack operate or respond according to the input received from users who are authenticated automatically with the help of a cookie saved on their systems. The attacker uses this stored authentication data in the cookie to access the browser for performing unintended actions such as changing account details, logging out of a session, buying a product, and uploading a site cookie. There are several ways to prevent CSRF. Security controls to block cross-site request forgery includes validating input, strongly encrypting communication between client and server, setting expiry time for cookies, looking for the referrer of the client request header to detect spoofing, and adding the randomization string known as nonce to each session and U-R-L request.

6 Configuration Baselining Hardening, Patching for Application Security

In this topic, you will learn about configuration baselining, hardening, and patching for applications to prevent application-based attacks. Baselining application configuration refers to including the least possible security controls for ensuring basic security to that application running in the same network environment. This baseline should be such that it strikes an effective balance between the functionality and security of the application. For this to happen, you should aim to have the most relevant and effective security controls. An application configuration baseline ensures complete compliance with policy and alleviates the risk of human oversight. You can create the baseline of initial settings or configuration while creating the deployment procedure. In fact, you can define a baseline at each stage of software development. Later, you can re-apply these baselines regularly or review them against the changing work environment as and when required so that they are updated according to the prevalent threats. The Information Security Policy, or ISP, usually governs the baselines. Application hardening refers to the process of modifying the default features or components by deleting or disabling the unnecessary ones. The aim here is to alleviate the number of vulnerabilities by decreasing the exposed attack surface. For instance, if a backend application is interacting with other applications only through a command prompt, it is wise to disable its Graphical User Interface, or GUI. Doing so nullifies the risk of possible vulnerabilities triggered by the corresponding GUI components. Application patch management aims to fix an identified vulnerability by using a patch developed by the vendor of that application. However, this is not a permanent or a one-time solution. A currently patched application might need to be patched later as another vulnerability may have been identified. This makes patch management a non-stop process of applying the right patches to an application. At times, it might so happen that a patch may stop an application from responding in a determined way. At this point, you should contact the vendor of that application for getting some solution or simply tweak the responding ability of the application along with its dependencies. It is advisable to apply a patch as soon as possible because it takes no time for the exploits to compromise the system and application in case a software vulnerability is detected. It is wise to test a patch before applying it to the networking environment.

7 NoSQL Databases for Application Security

In this topic, you will learn about NoSQL databases for application security and find out how they differ from SQL databases. NoSQL refers to a database approach for implementing non-relational data structures, which can be in the form of hierarchies or multilevel nesting. In a hierarchical structure, each data item has a single data-parent relation and zero, one, or several data-child relations. A data parent is located upward or closer to the hierarchy’s root, while a data child is located downward or away from the root. The Table element of HTML and XML data represent hierarchical data structures. A multilevel nesting is typically a cross-referencing structure where a data item can be linked to several data-parent and data-child items. In fact, a data object can even have links across several levels of data objects or items. In simple terms, you can link any data item to any other data item without adhering to any structural limitations. Some of the best examples of such multilevel nesting are the structures of social media relations such as on Facebook and Google+. Another example can be of two office premises in the same building sharing space of two different departments. So, how does NoSQL differ from SQL? Let’s find out! The table below distinguishes between NSQL and SQL. NoSQL has BASE that stands for Basically Available, Soft State, Eventually Consistent, while SQL database implements RDBMS, or Relational Database Management System. Most NoSQL databases let go of Atomicity, Consistency, Isolation, and Durability, or ACID, compliancy for scalability and performance. However, most SQL databases comply with ACID properties, guaranteeing highly reliable database transactions, while data replication and logging take up the responsibility of durability and data integrity. A transaction to NoSQL is not instantly written, which means there is a chance of two transactions conflicting with each other. This negatively affects the execution accuracy at that point in time. NoSQL databases do not implement a fixed schema like SQL databases, due to which permissions on a row or column cannot be isolated. This enforces the application managing the database to take of security of the NoSQL database. On the other hand, SQL databases have no transaction conflicts, have schemas, and support encrypted communications, role-based security, row and field access control, and user-level permissions on stored procedures. Schemas in NoSQL are dynamic, which means you can add information on the fly. There is no need for each row to have data for each column. In case of SQL, the schema is fixed due to which the row values are predetermined. NoSQL databases are cost-effective solutions because scaling is horizontal across the servers. However, SQL incurs much cost and leads to performance overhead, especially when there is more data to be stored and retrieved as scaling is vertical. Just keep in mind that different security requirements exist for implementing the SQL or NoSQL database.

9 Summary

Let us summarize the topics covered in this lesson. ? Fuzzing is a testing technique to discover inputs causing errors, crashes, and failures. ? Secure coding includes writing good exception handling routines and validating all inputs. ? Some of the most effective security controls for the programmer to prevent cross-site scripting attacks include input validation, defensive coding, and script-like input rejection. ? Some of the security controls for cross-site request forgery prevention includes adding a randomization string to a URL request and session as well as checking the referrer of the HTTP request header for spoofing. ? Application hardening imposes security by removing or disabling the unnecessary features and performing patch management. ? Having an application configuration baseline ensures policy compliance.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*