Web Application Assessment

We help you remove security risks from vulnerabilities that are in your system such as SQL injection and cross site scripting by performing a vulnerability assessment of your web application.

Service Overview

This is a security assessment service for detecting vulnerabilities in web application such as SQL injection and cross site scripting. Vulnerability assessment is regarded as an effective and necessary measure for preventing illegal access and information leakage, which have affected many websites in recent years. Through vulnerability assessment of web applications, Ierae Security helps construct secure systems that are essential to web applications such as e-commerce sites and SNSs that handle private and sensitive information. We detect vulnerabilities without solely depending on automatic assessment tools, but rather using a method that combines tools and manual techniques where our security engineers comb the system from the viewpoint of an attacker for logic-related issues as well as issues that arise from the use of technologies that have become popular in recent years. Once the assessment of your web application is over, we compile a report detailing how to reproduce the vulnerabilities that have been detected and outline the best measures against security risks.

Assessment Flow

  • STEP1

    Preparations for a Web Application Assessment

    Examine the structure of the system and determine the scope of vulnerability assessment

    We ask you to first specify the scope of web application assessment, after which we estimate the necessary workload.

    1. Interview your staff to examine the system structure

      We examine the structure of your system by studying its specification documents, interviewing your system representative, and accessing the actual application, in order to estimate the number of requests to be tested in our assessment.

    2. Determine the method of web application vulnerability assessment and give you an estimate

      We ask you to choose either a remote assessment that is conducted by accessing your system through the Internet or an on-site assessment where our security engineers visit a location from which the target application can be accessed. We then give you an estimate per request unit depending on your choice.

  • STEP2

    Performing a Web Assessment

    Perform web application vulnerability assessment both using tools and manually

    We perform a tool-based assessment of the target web application as well as a manual assessment from the viewpoint of an attacker to detect flaws that cannot be detected by tools.

    1. A tool-based vulnerability Assessment

      We perform a comprehensive analysis of the target system, to which tools are better suited, in order to detect vulnerabilities in your web application that are caused by wrong settings or a lack of security measures.

    2. A manual assessment that targets possible vulnerabilities in your web application system

      Our security engineers study the validity of the results of the tool-based assessment and examine assessment items that cannot be tested using tools, which all be done manually. It is sometimes the case with minor individual vulnerabilities that they create a large security risk when combined.

  • STEP3

    Submitting an Assessment Report and Proposing Measures to Improve Your Web Application

    Report on the Results of the Web Application Assessment

    We report on the details of the risk assessment results, executive summary, and vulnerabilities that have been detected in your web application.

    1. Overall Evaluation

      We report on the assessment results, and if one or more vulnerabilities have been detected, we explain how they may affect your business. We also propose measures that are recommended from the viewpoint of business operation.

    2. Details of the Vulnerabilities in Your Web Application

      We report on the details of the vulnerabilities, how to reproduce them, etc. We also outline what risks can arise from them and what countermeasures should be taken.

Assessment Items

Input and Output Handling

Cross Site Scripting
We inject tags and JavaScript into the parameter of each request that sends parameters to see if they will be displayed as is in the response.
SQL Injection
We inject characters having special functionalities in SQL statements into the parameter of each request that sends parameters and check the response.
Command Injection
We input operation commands such as set, cd, dir, etc. into the parameter of each request that sends parameters to see if there will be any changes in the response.
Directory Traversal
We input strings that traverse directories such as /../../../../etc/hosts into the parameter of each request that sends parameters to see if there will be any changes in the response.
File Upload
If your web application accepts file uploads, we check if files that are not in the specified format can be uploaded (for example by altering file extension). Also, if your web application allows users to access files that they have uploaded, we upload files containing scripts or programs and check if they can be executed.
HTTP Header Injection
We input a line break element (%0D%0A) into the parameter of each request that sends parameters which are shown in the response header, in order to see if a forced line break occurs.
Directing to a Phishing Website
We input URL of external website such as Google and Yahoo into the parameter of each request that sends parameters to see if the response redirects to the URL.
Parameter Manipulation
If values representing prices, membership points, or changes in membership points are sent to the server as parameters, we change them to negative values, etc., to see how it affects the execution results.
Third-Party Mail Relay
We input a line break element and a mail header into each parameter of requests that send parameters to check the response of the screen and the email that will be sent from your system.


Examination of the Login Form
We check if the password field is properly masked or not.
Examination of Login Error Messages
We check if user IDs or passwords can be guessed based on login error messages. Example: we compare error messages that will be displayed when the ID is correct and when the password is wrong and when both the ID and the password are wrong.
Examination Related to the Transmission of Login Credentials and Personal Information
We check the content of transmissions that are made when login credentials or personal information is sent or received.
Account Locking Function
If new accounts can be easily set up or if multiple accounts are available we enter wrong passwords multiple times and check if the account will be locked.
Logout Function
We check if there is an explicit way to log out from the system after logging in.
Authentication Bypass
We send requests for the post-login page from a browser without login to see if post-login pages will be displayed.


Privilege Elevation
If your system has both administrator and general user accounts, we check if general user accounts can run operations that require administrator privilege. We send requests for operations that require administrator privilege from a browser logged in as a general user and check if they can be executed.
Accessing Information without Authorization
If values representing user ID, group ID, or other unique values that represent which data to access are sent as parameters, we change the values to ones that users are not authorized to access and see if unauthorized access or modification is possible.

Session Management

Cookie with Secure Flag
If your website uses SSL, we check if Cookies that contain session information and other sensitive information have the secure flag.
Cookie Lifetime
We check if Cookies that contain session information and other sensitive information will be retained for an extended period of time.
Session ID Randomness Check
We check if session IDs that are contained in Cookies and parameters follow a certain rule when they are issued.
Session Fixation
We check if new session IDs are issued at login. Also, even if new session IDs are issued, we check if a login can be made with old IDs.
Session Fixation Attack
If a session fixation issue is present, we will create links or requests whose parameters for sending session IDs, such as PHPSESSID and jsessionid represent arbitrary session IDs, and have other users send them check if the user can use an arbitrary session ID.
Cross Site Request Forgery
We check if essential operations, such as changing login information, changing password, closing an account, or payments, can be executed by letting the user send certain requests.

Web Server Configuration

Allowed HTTP Methods
We check which methods are allowed based on the scan results. Alternatively, we send a request using the OPTIONS method and check which methods are supported.
Server Error Messages
We check if error messages containing a part of your source code, system information, etc., will be displayed when a character that is unexpected by the web application is entered. We also check if software information of the system can be obtained from the response header or error messages that are sent when accessing the web application.
System Information Disclosure
Also, if version information can be obtained, we investigate if the version has vulnerabilities.

Web 2.0

Flash Content Vulnerability
We check if the crossdomain.xml file exists, and if it does, we check the content of the file to see if it can be accessed from any domains.
Ajax Content Vulnerability
We inject tags and JavaScript into the parameter of each request made by Ajax that sends parameters to see if they will be displayed as is in the response.

General Vulnerabilities

Known Software Vulnerabilitis
If we obtain software information or version information of the software, we examine if the software has known vulnerabilities.
Forced Browsing
We attempt to access manual, icons, info.php, and other files without links by specifying the file URL directly to check if their content is displayed.
We also change the extension of the program to .bak and check.
Directory Listing
We segment the URL by directory /aaa/, etc., to see if the directory listing will be displayed.


A Major e-Commerce Enterprise

Vulnerability Assessment of an e-Commerce Website

Assessment Background
We received an order for security assessment of an updated version of an e-commerce website with several million users.
Our assessment discovered vulnerabilities in an added feature of the updated version that could lead to personal information leakage, which could have led to a fatal incident if left undetected.
Service Scale
Approximately 200 screens
Assessment Period
Approximately four weeks

A Major Telecommunications Company


Assessment Background
This company asked for security assessment of their sales and contract website prior to its release. We detected a flaw that allowed malicious contracts to be made and prevented any damage from it before the release of the website.
Service Scale
Approximately 150 screens
Assessment Period
Approximately three weeks

Sample Report

In the report of the assessment results, we present the details, reproduction procedures, risks, and countermeasures for the vulnerabilities that are discovered, so that the client company can correct them quickly.
*Please request a sample report on the inquiry page. A representative will send them within two business days.


Please do not hesitate to contact us.

Wishing to solve security issues in your web services or apps and maximize profit? Please do not hesitate to contact us, as we will be delighted to help you.
Our highly experienced security engineers will test your system.