JSP Secure Development Guide

Section 1. Security Countermeasures

1. Script Injection Vulnerability

A. Vulnerability Details and Security Countermeasures

This vulnerability refers to attacks that control a web browser to attack a PC by causing client-side scripts (such as JavaScript or VBScript) that run in a web browser to execute in another user’s browser. These attacks can be largely classified into two types.

(1) Reflected XSS

This type of XSS occurs when data sent from the client is immediately processed by the server and returned to the user in the response. It can occur in situations such as:

1. When a search term entered on a search page is displayed on the search results page.
2. When a specific parameter included in the URL is included as a hidden attribute in the response page.

Essentially, these two scenarios are identical. This type of XSS can be exploited by using social engineering to induce others to execute a URL containing an attack script (e.g., sending a link via messenger or posting a URL link on a bulletin board). However, since an attacker cannot forcibly execute an attack script on another user’s PC, it is generally not classified as a critical vulnerability. Nonetheless, for organizations where trust is paramount, such as public institutions or financial sectors, all Reflected XSS must be removed. It is generally recommended to remove them from any publicly accessible website.

(2) Stored XSS

This vulnerability occurs in web applications, such as bulletin boards, where information entered by a user is stored in the server-side database and then retrieved and displayed on the screen when another user views that information. This is considered the most core vulnerability of XSS. It poses a serious threat because it can execute attack scripts in the web browsers of an unspecified number of visitors. An attacker can insert malicious scripts for XSS purposes not only in the body of a post but also in titles, author names, dates, and attachment filenames. Additionally, scripts can be inserted into any user-input data, such as nicknames, addresses, and phone numbers in user profiles.

• Bulletin Boards: Title, Body, Author, Date, Attachment name, Tags, Category, etc
• User Profiles: Name, Nickname, Address, Phone number, Email, Occupation, and other input information.
• Any other user-input data.

B. Security Countermeasures

Security countermeasures for XSS should be divided into two cases depending on the target: when tags do not need to be used and when the use of tags must be allowed.

• When tags do not need to be used: Cases like internal bulletin boards or Reflected XSS where there is no need to allow HTML tags within strings.
• When tags must be used: Cases like public customer bulletin boards or community boards where users need to use tags within strings for formatting.

(1) When tags do not need to be allowed (Internal boards, Reflected XSS)

For simple bulletin boards like internal ones, XSS can be completely blocked by encoding the < and > characters into HTML Special Characters in all user-input data. Codes encoded as HTML Special Characters are displayed as normal strings in the web browser but do not function as tags or scripts, making them safe from XSS.

Target Character	HTML Special Character Code
<	&lt;
>	&gt;

Section 1. Security Countermeasures

1. Script Injection Vulnerability

A. Vulnerability Details and Security Countermeasures

This vulnerability refers to attacks that control a web browser to attack a PC by causing client-side scripts (such as JavaScript or VBScript) that run in a web browser to execute in another user’s browser. These attacks can be largely classified into two types.

(1) Reflected XSS

This type of XSS occurs when data sent from the client is immediately processed by the server and returned to the user in the response. It can occur in situations such as:

• When a search term entered on a search page is displayed on the search results page.
• When a specific parameter included in the URL is included as a hidden attribute in the response page.

Essentially, these two scenarios are identical. This type of XSS can be exploited by using social engineering to induce others to execute a URL containing an attack script (e.g., sending a link via messenger or posting a URL link on a bulletin board). However, since an attacker cannot forcibly execute an attack script on another user’s PC, it is generally not classified as a critical vulnerability. Nonetheless, for organizations where trust is paramount, such as public institutions or financial sectors, all Reflected XSS must be removed. It is generally recommended to remove them from any publicly accessible website.

(2) Stored XSS

This vulnerability occurs in web applications, such as bulletin boards, where information entered by a user is stored in the server-side database and then retrieved and displayed on the screen when another user views that information. This is considered the most core vulnerability of XSS. It poses a serious threat because it can execute attack scripts in the web browsers of an unspecified number of visitors.

An attacker can insert malicious scripts for XSS purposes not only in the body of a post but also in titles, author names, dates, and attachment filenames. Additionally, scripts can be inserted into any user-input data, such as nicknames, addresses, and phone numbers in user profiles.

• Bulletin Boards: Title, Body, Author, Date, Attachment name, Tags, Category, etc.
• User Profiles: Name, Nickname, Address, Phone number, Email, Occupation, and other input information.
• Any other user-input data.

---

B. Security Countermeasures

Security countermeasures for XSS should be divided into two cases depending on the target: when tags do not need to be used and when the use of tags must be allowed.

1. When tags do not need to be used: Cases like internal bulletin boards or Reflected XSS where there is no need to allow HTML tags within strings.
2. When tags must be used: Cases like public customer bulletin boards or community boards where users need to use tags within strings for formatting.

(1) When tags do not need to be allowed (Internal boards, Reflected XSS)

For simple bulletin boards like internal ones, XSS can be completely blocked by encoding the < and > characters into HTML Special Characters in all user-input data. Codes encoded as HTML Special Characters are displayed as normal strings in the web browser but do not function as tags or scripts, making them safe from XSS.

Target Character	HTML Special Character Code
<	&lt;
>	&gt;

Reflected XSS can occur for all variable values displayed on the screen (including hidden fields), so validation must be performed on all output values.

JSP

Since there is no built-in encoding function provided separately, you should write and use a function that filters < and > through replace statements.

resultStr = resultStr.replaceAll("<", "&lt;");
resultStr = resultStr.replaceAll(">", "&gt;");

Meanwhile, when creating presentation pages in JSP, using JSTL is convenient because all output values are automatically encoded, eliminating the need for manual replacement. (Highly recommended during the development stage.)

<c:out value="${value}" />

(2) When tags must be allowed (Public boards)

Response to Allowing Tags on Bulletin Boards

In communication-oriented web applications such as public bulletin boards, HTML tags cannot be completely prohibited because users want to decorate their posts or use links, images, and videos. Therefore, while < and > should generally be filtered, these characters should not be filtered for the specific tags that users need to use.

Consequently, website operators should select a minimum set of HTML tags to permit on their boards and then perform a reverse transformation only for those specific tags (i.e., reverting < and > that were replaced with < and > back to their original form).

Additionally, separate defense code must be written to address potential threats that may arise when allowing those specific tags. Defense code can be implemented using the following two methods:

A. Filtering via Word Blacklist

This method involves filtering words frequently used in XSS attacks to prevent them from being used. While simple to implement, it cannot block malicious code not included in the blacklist. Furthermore, as bypass techniques evolve, the filtering itself may be bypassed. Another drawback is that users are restricted from using the blacklisted words in their posts.

Blacklist Code Example

// blacklist 를 필터링하여 사용할 수 없도록 함
test_str_low= test_str.toLowerCase();
test_str = test_str_low;
test_str = test_str.replaceAll("javascript", "x-javascript");
test_str = test_str.replaceAll("script", "x-script");
test_str = test_str.replaceAll("iframe", "x-iframe");
test_str = test_str.replaceAll("document", "x-document");
test_str = test_str.replaceAll("vbscript", "x-vbscript");
test_str = test_str.replaceAll("applet", "x-applet");
test_str = test_str.replaceAll("embed", "x-embed");  // embed 태그를 사용하지 않을 경우만
test_str = test_str.replaceAll("object", "x-object");    // object 태그를 사용하지 않을 경우만
test_str = test_str.replaceAll("frame", "x-frame");
test_str = test_str.replaceAll("grameset", "x-grameset");
test_str = test_str.replaceAll("layer", "x-layer");
test_str = test_str.replaceAll("bgsound", "x-bgsound");
test_str = test_str.replaceAll("alert", "x-alert");
test_str = test_str.replaceAll("onblur", "x-onblur");
test_str = test_str.replaceAll("onchange", "x-onchange");
test_str = test_str.replaceAll("onclick", "x-onclick");
test_str = test_str.replaceAll("ondblclick","x-ondblclick");
test_str = test_str.replaceAll("enerror", "x-enerror");
test_str = test_str.replaceAll("onfocus", "x-onfocus");
test_str = test_str.replaceAll("onload", "x-onload");
test_str = test_str.replaceAll("onmouse", "x-onmouse");
test_str = test_str.replaceAll("onscroll", "x-onscroll");
test_str = test_str.replaceAll("onsubmit", "x-onsubmit");
test_str = test_str.replaceAll("onunload", "x-onunload");
}

B. Tag Property Validation Method

This method involves conducting individual validity checks on the properties of each permitted tag to filter out properties used in an abnormal manner. Although more complex to implement, it is safer because it rejects all unauthorized forms of input, making it less likely to be bypassed. Additionally, it has the advantage of not damaging the content of the user’s post.

For example, the following rules can be applied to the <img> tag to delete all properties that violate the rules:

Permitted Rules for img Tags

- Allow only src, width, and height properties for the img tag (ignore all other properties).
- For src, allow only image file paths starting with http:// (allow only extensions such as .jpg, .gif, etc.).
- For width and height, allow only numeric values.

The factors to consider when applying this method are as follows:

• Allow only the minimum necessary HTML tags.
• Allow only essential properties for each tag.
• Do not allow event-type properties such as onClick or onError.
• Strictly limit the format of the data inserted into each property. (e.g., only URL addresses should be allowed in the “src” property, and content such as “javascript:alert('test');” must not be entered.)

Due to the development of new HTML protocols and the advancement of web browsers, XSS attack patterns continue to emerge as new patterns…

2. SQL Injection Vulnerability

A. Vulnerability Details and Security Countermeasures

Websites interface with Database Management Systems (DBMS), meaning that data transactions occur based on user input values within the web application. If validation of these user input values is omitted, a malicious attacker can send manipulated inputs containing SQL query statements instead of normal values. This allows the attacker to alter the structure of the server-side query, which can be exploited to bypass user authentication, leak information from the database, or execute system commands on the server.

B. Security Countermeasures

(1) SQL Injection Defense Measures at the Database Operations Level

To defend against SQL Injection, DB or website administrators must adhere to the following management practices as a baseline:

• Grant Least Privilege to DB Accounts
  • Only the minimum necessary permissions should be granted to the database account used by the website.
  • System privileges (such as sysdba, sa, root, etc.) must not be granted to the database account.
• Preventing Error Exposure
  • Configure the web server or WAS (Web Application Server) to output standardized error pages whenever an error occurs. This prevents the exposure of internal database information through error messages.
• In the case of SQL Server, remove the xp_cmdshell extended stored procedure.

However, since the aforementioned methods alone are not enough to fully defend against SQL Injection, countermeasures to eliminate vulnerabilities at the source code level must be applied as follows.

(2) Preventing SQL Injection via Prepared Statements at the Source Code Level

(2) Preventing SQL Injection via Prepared Statements at the Source Code Level

If the website is currently under development, it should be designed with a structure that fundamentally prevents SQL Injection vulnerabilities by using Prepared Statements within DAO objects or database connection logic to handle DB transactions.

The Prepared Statement syntax pre-processes and compiles the SQL query first. Subsequently, any input variable values are treated strictly as string literals (data) rather than executable code. Therefore, even if a user inserts malicious SQL commands into a variable, it will not affect the structure of the SQL statement, effectively preventing SQL Injection.

Using Prepared Statements in JSP

The following is a simple example of how to construct a Prepared Statement in JSP.

Prepared Statement Syntax

// 객체 선언
Connection con;
PreparedStatement pstmt;
ResultSet rs;

// DB연결 생성
con = DriverManager.getConnection(-------);

// Query 문 및 변수값 세팅
pstmt = con.prepareStatement(“Select  name, id, num from Membertable where id=? And passwd=?“);
pstmt.setString(1, "test");             // 변수형에 따라 setXXXX 사용 ex) setInt, setDouble
pstmt.setString(2, "testpwd");

// Query 문 실행
rs = pstmt.executeQuery();          // executeQuery, executeUpdate

// 결과 처리
if (rs.next()){
	// rs 객체로부터 칼럼 이름을 이용한 결과값 추출하여 사용자 펑션의 실행
	Run_user_function (…, rs.getString(name), rs.getString(id), rs.getint(num));
	// 또는 인덱스를 이용한 결과값 추출
	Run_user_function (…, rs.getString(1), rs.getString(2), rs.getint(3));

}

// 객체 close
rs.close();
pstmt.close();

※ Note: Using Stored Procedures to handle database transactions can achieve the same security benefits as using Prepared Statement syntax.

(3) Preventing SQL Injection via Filtering at the Source Code Level

If it is difficult to refactor DB transaction logic to use Prepared Statements on a website that is already in operation, an alternative measure is to prevent SQL Injection by filtering special characters and query keywords.

For all parameters passed from the client that are used in DB query statements (e.g., board ID, post number, search keyword, user number, item number, category name, etc.), data should be processed as follows: filter out special characters and reserved SQL keywords, then either return an error or replace them with a backslash (”) or a space character.

Special Characters and Syntax to be Filtered
‘	union
“	select
–	insert
#	drop
(	update
)	from
;	where
@	join
=	substr (oracle)
*	user_tables (oracle)
/	user_table_columns (oracle)
+	subsring (ms-sql)
information_schema (mysql)	sysobjects (ms-sql)
table_schema (mysql)	declare (ms-sql)

Sample Filtering Code in JSP

Sample Filtering Code

// 특수문자 필터링을 위해 특수문자를 정의
Pattern evilChars = Pattern.compile("['\"\\-#()@;=*/+]");
// 특수문자는 모드 공백으로 치환
test_str = evilChars.matcher(test_str).replaceAll("");

// 특수 구문 필터링 (데이터베이스가 Oracle 인 경우)
test_str_low= test_str.toLowerCase();
if(test_str_low.contains("union") || test_str_low.contains("select") || test_str_low.contains("insert") || test_str_low.contains("drop") || test_str_low.contains("update") || test_str_low.contains("delete") || test_str_low.contains("join") || test_str_low.contains("from") || test_str_low.contains("where") || test_str_low.contains("substr") || test_str_low.contains("user_tables") || test_str_low.contains("user_tab_columns"))
{
test_str = test_str_low;
test_str = test_str.replaceAll("union", "q-union");
test_str = test_str.replaceAll("select", "q-select");
test_str = test_str.replaceAll("insert", "q-insert");
test_str = test_str.replaceAll("drop", "q-drop");
test_str = test_str.replaceAll("update", "q-update");
test_str = test_str.replaceAll("delete", "q-delete");
test_str = test_str.replaceAll("and", "q-and");
test_str = test_str.replaceAll("or", "q-or");
test_str = test_str.replaceAll("join", "q-join");
test_str = test_str.replaceAll("substr", "q-substr");
test_str = test_str.replaceAll("from", "q-from");
test_str = test_str.replaceAll("where", "q-where");
test_str = test_str.replaceAll("declare", "q-declare");
test_str = test_str.replaceAll("openrowset", "q-openrowset");
test_str = test_str.replaceAll("user_tables","q-user_tables");
test_str = test_str.replaceAll("user_tab_columns","q-user_tab_columns");
test_str = test_str.replaceAll("table_name","q-table_name");
test_str = test_str.replaceAll("column_name","q-column_name");
test_str = test_str.replaceAll("row_num","q-row_num");
}

3. File Upload

A. Vulnerability Details and Security Countermeasures

If uploading script files with executable extensions is permitted on bulletin boards or other platforms with file attachment features, an attacker can upload and execute malicious programs. By executing these malicious programs (often referred to as WebShells), an attacker can gain web server user privileges. Subsequently, they may attempt to intrude into the internal network or connect to the database to leak sensitive information.

B. Security Countermeasures

(1) Security Countermeasures from a Server Operations Perspective

From a server operations standpoint, the following measures should be applied to minimize damage from upload vulnerabilities. These ensure that even if a malicious file is uploaded due to a source code vulnerability, the attacker cannot execute it.

• Remove script execution permissions from the upload directory
• Locate the upload directory outside the sub-tree of the web root directory (e.g., Apache’s DocumentRoot) within the server’s directory structure, so that the upload directory cannot be accessed directly via a URL from the user’s web browser.

(2) Security Countermeasures from a Source Code Perspective

You must add a module to the web application’s source code to filter and restrict executable files from being uploaded to the server as follows.

ASP	.asa, .asp, .cdx, .cer, .htr, .aspx
JSP	.jsp, .jspx
PHP	.html, .htm, .php, .php3, .php4, .php5

The list of extensions provided in the table above corresponds to a general configuration environment, but the types of extensions recognized as executable by each server-side script engine vary according to specific server settings. Therefore, if there are any separately registered executable extensions, they must be added to the restriction list.

Meanwhile, when actually implementing filtering logic, the whitelist filtering method is generally recommended as it is safer than the blacklist method (which allows everything except the listed items). This is because the blacklist method carries the risk of omitting restricted keywords and may be bypassed through techniques such as string encoding.

Whitelist filtering is a method of strictly selecting only the list of permitted extensions (e.g., .jpg, .doc, .xls, etc.) and restricting all other extensions.

The extension filtering logic should generally be implemented according to the following principles.

• Filtering must be implemented on the Server-Side.
• When checking file extensions, implementation must be carefully done to ensure filtering is not bypassed by string-based tricks:
  • Compare regardless of case or convert the entire string to lower case for comparison (e.g., test.JsP, test.jsP, etc.).
  • Compare the extension at the far right of the filename to prevent bypass techniques such as “test.gif.jsp”, “test.jsp.”, or “test.jsp;test.jpg”.
• When saving uploaded files, change the filename and extension to random strings and non-executable extensions that cannot be guessed. (Recommended)
• Store the storage path and filename in a database and call them via an index number to prevent the exposure of filenames and paths to the outside. (Recommended)

The last two application items mentioned above are not mandatory for servers already in operation, as they require complex logic changes during implementation. However, for environments where absolute security is essential—such as the financial sector—or when security is being considered during the development stage, it should be recommended to apply these two logics.

Source Code Security Countermeasures in JSP

• Example of File Extension Extraction Code

Example of File Extension Extraction Code

<%
   String filePath = "/test/test.jsp";
String fileExt = filePath.substring(filePath.lastIndexOf('.') + 1).toLowerCase();
%>

• Blacklist-based Filtering Code Example
  In the case of JSP running on a Windows server, vulnerabilities related to “; (semicolon)” parsing may occur. Furthermore, when using blacklist-based filtering, issues related to “. (dot)” can arise. Therefore, processing code for these must be included. (JSP running on Unix is not affected by these specific issues.)

Blacklist-based Filtering Code Example

<%

Boolean checkResult = true;

// 업로드 금지 확장자 리스트
String blockExt[] = {"jsp","jspx"};

// 금지할 확장자 체크
for(int i=0; i<blockExt.length;i++) {
if( blockExt[i].equals(fileExt) ){
checkResult = false;
break;
    }
}

// Windows일 경우 (.) 및 세미콜론 파싱 오류 관련 처리
if(fileExt.length() == 0 ) {
checkResult = false;
}
if(filePath.contains(";")) {
checkResult = false;
}

if(checkResult == false){
out.println ("업로드가 금지된 파일 입니다.");
}else{
out.println ("업로드가 허용된 파일 입니다.");
}

%>

• Whitelist-based Filtering Code Example
  In the case of JSP running on a Windows server, vulnerabilities related to “; (semicolon)” parsing may occur, so processing code to handle this must be included. (JSP running on Unix is not affected by this.)

Whitelist-based Filtering Code Example

<%

Boolean checkResult = false;

// 업로드 허용 확장자 리스트
String allowExt[] = {"doc","docx","xls","xlsx","jpg","gif","txt"};

// 허용할 확장자 체크
for(int i=0; i<allowExt.length;i++) {
if( allowExt[i].equals(fileExt) ){
checkResult = true;
break;
    }
}

// Windows일 경우 세미콜론 파싱 오류 관련 처리
if(filePath.contains(";")) {
checkResult = false;
}

if(checkResult == false){
out.println ("업로드가 금지된 파일 입니다.");
}else{
out.println ("업로드가 허용된 파일 입니다.");
}

4. File Download

A. Vulnerability Details and Security Countermeasures

By inserting path traversal strings into the parameters of a web application’s download module, an attacker can access the OS file system located above the web root directory. This can be exploited to download various critical system files and the source code of web programs.

B. Security Countermeasures

To remain secure from file download vulnerabilities, it is generally recommended to implement the download module as follows:

• When implementing the file download module, store the actual file paths in a database. Use an index number in the URL parameters exposed to the user to identify the file to be downloaded. This prevents path information from being exposed, leaving no path details for a user to attempt to manipulate.

However, implementing the above method requires somewhat complex modifications to the website logic. Therefore, for sites such as internal employee portals—excluding those highly sensitive to information exposure like public institutions or banking sites—the following filtering code can be applied as an alternative to resolve the vulnerability:

• Filter path traversal strings that represent parent directories (e.g., [..], [../], [..]) from the parameter variables that handle file paths in the download module to prevent their use.
• Designate a specific directory allowed for downloads and prohibit any download requests for locations outside that directory, issuing a warning message instead.

Example of Filtering Code Implementation in JSP

Example of Filtering Code Implementation in JSP

<%
// 다운로드 허용할 디렉토리 설정
String allowPath = "/server/upfiles/";

// 파라미터로부터 다운로드할 파일을 입력 받아 전체 경로를 생성함
String inputPath = getParameter("downfile");
String filePath = allowPath + inputPath;

// 금지 문자열 리스트
String blockchar[] = {"..", "../", "..\\"};

Boolean checkResult = true;

// 금지할 문자열 포함 여부 체크
for(int i=0; i<blockchar.length;i++) {
if( filePath.indexOf(blockchar[i]) != -1 ){
checkResult = false;
}
}

// 파일 전체 경로로부터 디렉토리 경로만 추출한 후, 다운로드 허용된 디렉토리인지 체크
String path = filePath.substring (0, filePath.lastIndexOf("/") + 1).toLowerCase();
if( !path.equals(allowPath) ){
    checkResult = false;
   }

if(checkResult == false){
out.println ("다운로드가 금지된 파일 입니다.");
}else{
out.println ("다운로드가 허용된 파일 입니다.");
}

%>

5. Forced URL Access / Authentication Bypass

A. Vulnerability Details and Security Countermeasures

Every individual web page must include its own authentication and authorization management module. Otherwise, an unauthenticated user can force access by directly entering the URL of a specific page. Furthermore, authentication and authorization modules must be implemented securely. If the logic is vulnerable to bypass or if authorization management is improperly handled, serious issues such as illegal access, unauthorized role assumption, leakage of sensitive information, or unauthorized use of services may occur.

B. Security Countermeasures

Forced URL access or authentication bypass vulnerabilities arise from flaws in the website’s authentication and authorization management modules. To resolve this, appropriate verification must be performed for every page on the website. This is commonly implemented by creating a common module for authentication and authorization and including it in every page.

The primary causes of vulnerabilities in these modules are:

• Cases where the module exists but is missing from specific pages.
• Cases where vulnerabilities exist in the implementation of the module, allowing for bypass.

(1) 특정 페이지에 인증 및 권한 관리 모듈이 누락된 경우

(1) Missing Authentication/Authorization Modules on Specific Pages If a module exists but has been omitted from certain pages, the issue can be resolved by adding the common module to those pages. However, since this type of vulnerability is often found across multiple pages, there is a high probability that undiscovered pages remain unless a full inspection of every page was conducted during a vulnerability assessment or penetration test.

Therefore, website administrators or maintenance developers are recommended to review all pages of the website, not just the reported locations, when addressing this vulnerability. Each page should be reviewed for the following:

• Does this page require authentication for access?
• Are authentication and authorization properly verified for every user accessing this page?

(2) Vulnerabilities in the Module Allowing for Bypass

While vulnerabilities in authentication and authorization modules manifest in various forms across different sites, the following points should be observed when designing or modifying modules to supplement security:

• The initial state for granting authentication and authorization should be “deny” by default. Implementation should only “allow” users who have been granted the necessary permissions.
• When implementing Role-Based Access Control (RBAC), simply hiding menus or links from the screen for unauthorized users is insufficient. If the page itself lacks verification logic, it remains vulnerable to forced URL access. Permissions must be validated on every page regardless of whether the link is visible.
• If a task requiring specific permissions is performed through a series of steps (flow), authentication and authorization must be verified at every stage, including intermediate steps. (e.g., Editing a post involves entering content in a “form” page, updating data in an “action” page, and redirecting to a “view” page; authentication and authorization must be verified separately on the form, action, and view pages.)
• When an unauthorized access attempt occurs and the page is redirected via JavaScript (e.g., location.href='/error/accessDeny.jsp'), the page executing that redirection script must not contain any of the actual sensitive content of the restricted page.

6. Cookie Manipulation Vulnerability

A. Vulnerability Details and Security Countermeasures

Cookies are a technical method used to facilitate user session management, considering the stateless nature of the HTTP protocol. They are primarily used to store website settings to maintain a consistent user experience or to handle information related to user authentication. However, because Cookies are fundamentally a client-side session technology, the values transmitted can be manipulated by the user. If critical information is included in Cookie variables, an attacker can bypass authentication or steal other users’ information by tampering with those values through the web browser. Furthermore, variables passed via Cookies are susceptible to attacks such as SQL Injection and parameter manipulation, just like variables passed through GET or POST methods.

B. Security Countermeasures

(1) Use of Session-based Mechanisms

The traditional method of using Cookies to store and transmit plaintext information between the server and client is no longer recommended. Server-side script engines, such as WAS (Web Application Servers), support “Sessions,” a more advanced form of state management. The Session method provides a storage area on the server to save user-specific information, such as authentication data or settings, and identifies this storage via an encrypted Cookie variable (Session ID). Since the actual information cannot be tampered with on the client side, it is much more secure than the Cookie method. Therefore, critical information that must not be forged, such as authentication or authorization data, should ideally be implemented using the Session method.

2) Encryption of Cookie Variables and Input Validation

If it is necessary to store and transmit data in Cookie variables, and that data involves critical information like authentication or authorization, it must not be used in plaintext. The information must be encrypted using recognized encryption algorithms such as SEED, 3DES, or AES before use. Even if the information is not considered critical, values passed via Cookie variables are still subject to attacks like SQL Injection, XSS, and parameter manipulation. Proper input validation must be performed to defend against these vulnerabilities:

• SQL Injection Prevention: If values passed through Cookies are used in logic that interacts with a database, countermeasures against SQL Injection must be applied.
• Logic Validation: If Cookie variables are used in critical website logic, such as shopping carts or payment modules, appropriate validity checks must be performed to prepare for the possibility of variable manipulation.

7. URL Parameter Manipulation

A. Vulnerability Details and Security Countermeasures

Attackers can infer the logic and roles of server-side programs through data exposed in GET/POST parameters of a web URL, <INPUT> variables in HTML code, hidden fields, or JavaScript variables. By intentionally tampering with these variable values and transmitting specific data, they can attempt to manipulate server-side programs to perform unauthorized tasks.

If website logic is not carefully designed, tampered input values sent by an attacker can cause unintended malfunctions or illegal operations that exceed the normal processing scope of the server-side program.

The types of threats arising from parameter manipulation vary greatly depending on the type of website and the functions it provides. Common types of high-frequency vulnerabilities include:

• Unauthorized viewing/modification/deletion of other users’ posts by manipulating post numbers.
• Arbitrary changes to user roles on role-based websites.
• Tampering with payment data, such as product prices, during online transactions.
• Unauthorized viewing and modification of other users’ information by tampering with IDs, employee numbers, etc.
• Bypassing real-name authentication during membership registration.
• Unauthorized viewing or tampering of information with restricted access.
• Bypassing authentication logic, uploading malicious files, or unauthorized downloading of server-side resources.

B. Security Countermeasures

To defend against attacks via parameter manipulation, server-side programs must be designed with the constant consideration that information transmitted from the client may have been tampered with. Most data sent from the client—including GET/POST variables, Cookie variables, HTTP Headers, and Referers—can be manipulated.

Therefore, when designing critical operations such as authentication, payment, or the viewing/modification of information, logic must be carefully designed with the following precautions:

• Validate Request Authority: When performing critical operations, you must verify that the task was requested by a user with appropriate permissions based on trusted information that cannot be manipulated by the client, such as information stored in Session objects.
• Cross-verify Multi-step Flows: For tasks performed through multiple steps, compare and verify variables used at the start and end of the flow to ensure specific variables were not tampered with during intermediate stages. (e.g., When processing membership registration, verify at the final saving stage whether the name/resident registration number that passed real-name authentication in the first stage was altered during the process.)
• Use Trusted Data Sources: Avoid using variable values received from GET/POST parameters for information that serves as a standard for critical operations (e.g., product price in a payment module, user ID during profile modification). Instead, read and use information from trusted repositories like Session objects or databases. (e.g., Product prices should be retrieved from the DB, and the user’s ID should be retrieved from the Session object.)

This type of vulnerability manifests in various forms depending on the structure, type, and service category of the target. Therefore, the specific characteristics and logic of each target must be analyzed to apply the most appropriate security measures.

8. Weak ID/PW

A. Vulnerability Details and Security Countermeasures

For web pages that can only be accessed after passing login authentication, the use of weak accounts allows an attacker to attempt dictionary attacks using commonly used words based on website information or acquire weak accounts through brute-force methods. If default accounts provided by the system, DBMS, or application servers for management purposes are used without modification, their existence can be easily exposed to attackers. Likewise, general user accounts can also be exposed to attackers through various methods.

B. Security Countermeasures

Password generation rules must be established to prevent users from using weak passwords, and logic to guide and enforce these rules must be applied.

• Examples of Password Generation Rules
  • Prohibit the use of easily guessable account names such as “admin” or “master.”
  • Passwords must be at least 8 characters long and consist of a mixture of numbers, letters, and special characters.
  • Prohibit creating passwords using personal information (e.g., passwords similar to the account ID).
  • Prohibit the consecutive use of simple characters (including English words) or numbers.
  • Prohibit the use of dictionary words, their reverse spellings, or words with a single number added.
  • Create passwords that are easy to remember so that separate records are not necessary.
  • Prohibit selecting passwords that follow a sequential pattern on the keyboard.
  • Passwords must be changed periodically.
  • Set a minimum and maximum usage period for passwords.
  • Prohibit the reuse of previously used passwords.

9. Directory Indexing

A. Vulnerability Details and Security Countermeasures

Due to errors in web server configuration or for convenience during development, file lists within web directories may be set to display through a web browser. If the file list of a web directory is exposed, information regarding the website’s structure and environment may be revealed to an attacker. Furthermore, if backup files or configuration files exist within the web directory, an attacker can download these files to obtain critical website information.

B. Security Countermeasures

Identify the web server in use and change the settings in the configuration file or management console to disable Directory Indexing.

• Apache To prevent a list of all files in the DocumentRoot directory from being displayed, remove the “Indexes” option from the “Options” directive in the <Directory> configuration section of the httpd.conf file. Removing the Indexes option from the top-level DocumentRoot applies to all subdirectories; however, if the Indexes option is specifically added to a certain subdirectory, the subdirectory’s setting takes precedence. Therefore, ensure that all Indexes options in subdirectories are also removed.

<Directory “/usr/local/www”>
    Options Indexes FollowSymLinks     (---> Indexes 지시어 삭제)
    AllowOverride None
</Directroy>

• IIS
  Go to Internet Information Services (IIS) Manager → [Target Website] → [Properties] → [Home Directory] → Uncheck the Directory Browsing checkbox.

• WebtoB
  Check whether a DIRINDEX section is inserted in the configuration file and verify the settings related to the DIRINDEX section in the NODE section. Either do not insert the DIRINDEX section or set the Options value to -index.
  (※ Configuration file: ${WEBTOBDIR}/config/[filename.m])

*NODE
nex-edfa87d356c	WEBTOBDIR="C:/TmaxSoft/WebtoB4.1", 
		SHMKEY = 54000,
		DOCROOT="C:/TmaxSoft/WebtoB4.1/docs",
		PORT = "8080", 
		HTH = 1,
		LOGGING = "log1",
		ERRORLOG = "log2",
		JSVPORT = 9900,
		DirIndex = "diridx_full",
		Options = "-index"

*DIRINDEX
diridx_full	Options = "Fancy"

10. Default Page

A. Vulnerability Details and Security Countermeasures

When platforms such as web servers or WAS (Web Application Servers) are installed with default options, various examples, sample pages, installation information, and management consoles provided for user convenience are installed together. These features are generally installed in the same paths for each product, and since installation details are publicly available, they can become primary targets for attackers. In particular, cases have been reported where vulnerabilities existing in sample pages were exploited as attack vectors. Therefore, as unmanaged sample pages can act as security vulnerabilities, it is advisable not to install or to delete unused features. If certain features must be used, accidents should be prevented through thorough manageme

B. Security Countermeasures

Identify the web servers, WAS, databases, and other third-party products currently in operation, and review and delete any unnecessary features among those installed by default for each product.

• Deletion of Unnecessary Sample Pages and Features
  • Delete the Default Page and Banner of the web server/WAS.
  • Delete the PHP phpinfo page.
  • Delete usage examples and sample domains of the WAS, etc.
  • Stop or delete unused features among the management consoles of Tomcat, Jeus, IIS, WebLogic, etc.
  • Delete management pages and sample pages of other third-party product groups.
• Strengthening Management When Using Default Pages
  • If default pages or management consoles must be used, change the default settings for the access path and access port.
  • Do not use the default accounts created during the installation of management consoles; create and use separate accounts instead.
  • Apply appropriate ACL (Access Control List) policies for critical functions such as management consoles.
  • Ensure that management pages of third-party product groups are not exposed to the general public.

11. Backup Files

A. Vulnerability Details and Security Countermeasures

If compressed backup files or test files exist within a web directory with guessable names, they can be downloaded or their contents displayed in a browser without any special process. This poses a threat where sensitive information may be exposed.

B. Security Countermeasures

Check the following items and take appropriate action if they are discovered.

• Administrators must inspect web directories and delete all backup files such as *.asp.bak, *.jsp.bak, and *.php.old.
• Plain text files like *.txt created during web page development, as well as other non-essential image files, must be removed. Unnecessary *.bak files other than script backups should also be deleted.
• Since it is difficult for administrators to know exactly when backup files are created, it is recommended to use tools like cron to periodically inspect and delete them. Ideally, all files except those strictly necessary to run the web server should be removed.

12. Insufficient Error Pages

A. Vulnerability Details and Security Countermeasures

Attackers attempt to cause various errors to understand the status of a target system. By analyzing the resulting error messages, they can infer the structure and configuration of the web program to aid their attack. Therefore, custom error pages should be created to redirect users when an error occurs, preventing the exposure of unnecessary information. This includes “footprinting” attempts, such as using SQL Injection to discover the structure of SQL query statements.

B. Security Countermeasures

Ensure that error messages are not provided externally for any errors (404, 403, 500, etc.). When an error occurs, do not display the specific error message in the user’s browser; instead, redirect them to the main page or a specifically designed custom error page.

• Apache Error Page Configuration

Apache Error Page Configuration

# Custom error response messages (Apache style)
# Available in 3 ways:
#
# 1) Plain text
#ErrorDocument 500 "The server made a boo boo.
# Note: The " mark indicates text and is not printed itself.
#
# 2) Local redirection
#ErrorDocument 404 /missing.html
# Redirect to a local URL /missing.html
#ErrorDocument 404 /cgi-bin/missing_handler.pl
# Note: Can be redirected to a script or SSI.
#
# 3) External redirection
#ErrorDocument 402 http://some.othercom.com/subscription.html
# Note: A significant number of environment variables related to the original request cannot be passed to the script. While internal redirection works perfectly, errors can occasionally occur during external redirection.
ErrorDocument 400 /message/400error.html
ErrorDocument 401 /message/401error.html
ErrorDocument 403 /message/403error.html
ErrorDocument 404 /message/404error.html
ErrorDocument 405 /message/405error.html
ErrorDocument 500 /message/500error.html
ErrorDocument 501 /message/501error.html
Alternatively, variables can be passed using a script.
ErrorDocument 400 /message/error.php?ecode=400
ErrorDocument 401 /message/error.php?ecode=401
ErrorDocument 403 /message/error.php?ecode=403
ErrorDocument 404 /message/error.php?ecode=404
ErrorDocument 405 /message/error.php?ecode=405
ErrorDocument 500 /message/error.php?ecode=500
ErrorDocument 501 /message/error.php?ecode=501

• IIS Error Page Configuration
  In Internet Information Services (IIS) Manager, go to [Properties] – [Custom Errors] tab and set the error display pages accordingly.

13. Encryption of Sensitive Information in Transit

A. Vulnerability Details and Security Countermeasures

If account credentials or user information are transmitted over the internet without SSL or encryption, attackers can monitor network traffic in adjacent networks or wireless LAN environments to collect and obtain sensitive data. Even when SSL/encryption is applied, vulnerabilities can arise if weak algorithms are used or if there are errors in SSL configurations and certificates. Many websites apply SSL only to specific pages due to performance concerns, but this often leads to the omission of encryption on other pages that still handle sensitive data.

B. Security Countermeasures

The easiest way to safely defend the internet transmission section is to apply SSL or encryption to the entire website. However, due to performance issues, in most cases, encryption and SSL are applied only to pages that handle sensitive information.

When applying encryption and SSL to a website, the following principles should be observed at a minimum:

• Apply to all pages handling sensitive data and ensure no pages are omitted.
• Be mindful that sensitive information may be included not only in Request data like GET/POST but also in <INPUT> variables or JavaScript variables within the HTML Response code; ensure encryption is not omitted for these.
• Configure certificates accurately when applying SSL to prevent certificate warning windows from appearing in the user’s web browser. (Forcing users to ignore warning windows to use the web weakens their defenses against Phishing attacks, ultimately leading to increased phishing threats.)
• Ensure that requests made via plain HTTP for web pages requiring SSL are always redirected to the SSL (HTTPS) page.
• Implement appropriate encryption using symmetric/asymmetric keys for login credentials. If account information is transmitted using simple encoding or hash values, that information can be used as an authentication value to bypass login even without decryption (Replay attacks).

14. Exposure of User and Critical Information

A. Vulnerability Details and Security Countermeasures

The exposure of user personal information and critical information through a website occurs due to a wide variety of causes. For example, there are cases where information is exposed through simple operational mistakes in website management, and there are also types where information is exposed as a result of attacks on website configuration errors or security vulnerabilities.

Looking at representative types of information exposure due to operational mistakes on a website, examples include abandoned and unmanaged bulletin boards, old versions of websites that have not been deleted, inadequate management of backup files, Excel files or posts uploaded by an administrator’s mistake, and cases where private posts are exposed to everyone due to configuration errors.

In addition, types arising from website configuration errors or security vulnerabilities include cases where encryption is insufficient, direct leakage of server-side resources through file upload or file download vulnerabilities, leakage of file lists via directory indexing, cases caused by parameter manipulation vulnerabilities, and cases where database data is directly leaked through SQL Injection.

Therefore, to resolve this, constant website inspection efforts by the person in charge of operations and measures to eliminate security vulnerabilities must be applied comprehensively.

B. Security Countermeasures

The website operations manager must constantly check the following:

• Are there any personal information included in the posts uploaded to the announcements?
• Are there any personal information included in the attachments uploaded to the bulletin board?
• After a website renewal, is the old version of the website left unattended in a state where it is still accessible?
• Are there any unmanaged or unnecessary ports allowed on the website? (e.g., when both port 80 and port 8080 are allowed, but Web Application Firewall or SSL is not applied to port 8080)
• Is the access Role setting for public/private bulletin boards or services being managed appropriately?
• Are there any pages where the application of Web Application Firewall or SSL is missin

In addition, the following policies must be applied to prevent social engineering-type information leaks:

• When entering sensitive information such as resident registration numbers or passwords, process them as ‘*’ on the screen.
• Devise measures to prevent site operators from gaining unauthorized access to and viewing members’ personal information through administrator pages, etc.
• Log all access to sensitive information and store those logs in accordance with regulations.

15. Administrator Page Access

A. Vulnerability Details and Security Countermeasures

If administrator functions are not separated from general user functions, the paths to these functions are easily exposed. This can lead to access attempts by general users through the exposed paths or trigger continuous attacks by malicious actors. Administrator pages must have appropriate access controls. If they are accessible from arbitrary locations without control, their location can be exposed through path guessing or various other methods, potentially leading to brute-force attacks by malicious attackers.

B. Security Countermeasures

Administrator pages must be protected by the following security policies:

• Administrator pages should be developed separately from the general user interface. (e.g., using separate ports, domains, etc.)
• Appropriate access control procedures must be applied to ensure that administrator pages cannot be accessed from arbitrary locations (e.g., IP access control, SMS authentication, etc.).
• Easily guessable directory or file names must not be used.

Examples of guessable administrator pages:

http://www.abc.com/admin.html
http://www.abc.com/admin_main.html
http://www.abc.com/admin/index.html
http://www.abc.com/admin/login.html
http://www.abc.com/master.html
http://www.abc.com/master/index.html

16. WebDAV Vulnerability

A. Vulnerability Details and Security Countermeasures

If WebDAV, a remote management feature installed by default on Windows server computers, is set to remain enabled and write permissions are allowed for both the WebDAV library file properties and the website directory, a hacker can use WebDAV tools to remotely insert arbitrary files into the website directory and deface the site.

B. Security Countermeasures

If remote web server management is not being used, the WebDAV feature must be disabled. In addition to the vulnerabilities described above, WebDAV also has other issues such as buffer overflow vulnerabilities, so simply having the WebDAV feature in an “enabled” state can be problematic.

(1) If not using IIS

• Go to [Start] – [Programs] – [Administrative Tools] – [Computer Management] – [Services and Applications] – [Services] > Right-click [World Wide Web Publishing Service] Properties – [General] > Set Service Status to “Stop” and Startup Type to “Disabled”.

(2) If using IIS

• Find the following key in the Registry Editor (Regedt32.exe) and modify or add the value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters
Value Name: DisableWebDAV
Data Type: DWORD
Value Data: 1

• For IIS 6.0 or higher, stop the WebDAV item in the Internet Information Services (IIS) Manager.

17. Exposure of Sensitive Information in Search Engines

A. Vulnerability Details and Security Countermeasures

Because search engine results, such as those from Google, are stored and maintained in the search engine’s own database, once sensitive information is exposed in search results, the leak continues even if the information is deleted from your website, as it remains in the search results for a certain period. Therefore, sensitive information must be posted on pages that can only be accessed through authentication to ensure it is not inadvertently leaked by search engines. If information is confirmed to be exposed, you must directly request the search engine to delete that information. Additionally, you should periodically check search engine results by combining your website’s URL with keywords for sensitive information to verify if any information that should not be public is being exposed. For information you do not want to be indexed, you should use the robots.txt file settings to deny search access.

B. Security Countermeasures

(1) Deletion of Sensitive Information Exposed in Search Engines

If sensitive information is exposed, it will remain in search results for a period even after deletion from your site. Therefore, you should directly request deletion from the respective search engine.

• Google: Provides a web page for removing search results (https://www.google.com/webmasters/tools/removals?hl=ko)
• Naver: Contact the customer center to request deletion (http://help.naver.com/ops/step2/mail.nhn?catg=362)
• Daum: Select “Site, Web Document, Web News Inquiry” > “Delete Web Document” in the customer inquiry form (http://cs.daum.net/mail/form/15.html)

(2) Settings to Prevent Search Engine Indexing

* robots.txt Configuration

Most search engines follow the robots.txt protocol. By creating and applying a robots.txt file, you can deny access to URLs you do not want exposed.

To block all search engines from the entire site:

User-agent: *
Disallow: /

To block all search engines from specific directories:

User-agent: *
Disallow: /my_directory1/
Disallow: /my_directory2/my_directory3

To block a specific search engine from the site:

User-agent: Googlebot
Disallow: /

Precautions for robots.txt:

• The robots.txt file must be located in the root directory of the web URL.
• Directory paths in robots.txt represent the directory tree structure excluding the domain address.
• Since robots.txt is a text file accessible to anyone via URL, it must not include sensitive paths like administrator page locations.

Meta Tag Configuration (Denying search for specific pages)

ou can use meta tags to refuse information collection for specific pages. Insert the following syntax between the HTML <head> tags:

<meta name="robots" content="noindex, nofollow">

Testing Search Results in Google

Periodically check search results using keywords like the examples below to see if sensitive information is exposed:

- inurl:www.myweb.co.kr filetype:doc
- inurl:www.myweb.co.kr 고객명단
- inurl:www.myweb.co.kr admin

18. Special Character Vulnerabilities

A. Vulnerability Details and Security Countermeasures

Web servers and WAS (Web Application Servers) have had several reported issues in the past where bugs in the processing of special characters—such as ‘Null’, ‘%00’, ‘%3f’, ‘#’, and ‘::’—lead to the exposure of requested URL source code or the display of directory listings, depending on the product and version. Therefore, website operations managers should always check patch information and security advisories provided by the vendors of the products used on their websites. They should test whether their servers are affected by security issues and apply appropriate security measures. Additionally, they must test whether the websites they operate are affected by past special character processing vulnerabilities and, if found to be vulnerable, resolve them immediately.

B. Security Countermeasures

After checking the items below, if a vulnerability is confirmed, check the vendor’s security advisory and install security patches or change the web server/WAS settings as instructed.

Resin versions prior to 2.x / Other Java-based Web Application Servers (Common)

Outputs a directory listing when entered as follows:

• http://www.sample.com/sample/%3f.jsp

* JEUS

Outputs the source code of the requested URL or a directory listing when entered as follows:

• http://www.sample.com/sample/test.jsp#aaa
• http://www.sample.com/sample/#.jsp

Outputs the source code of the URL when entered as follows:

• http://www.sample.com/test.jsp::$DATA

* Platform Common

Test URLs with the following special characters inserted and check the web server’s response. If an unusual response occurs (e.g., source code output or directory listing) instead of a normal 400, 403, 404, or 500 error, search for the issue in the vendor’s security advisory and apply measures according to the instructions.

List of Special Characters to Test:

[.], [%2E], [+], [%2B], [%2A], [\], [%5C], [?], [%3F], [%20], [%00]

URL patterns to test (using %2E as an example):

• http://www.sample.com/test/%2E
• http://www.sample.com/test/test.jsp%2E