Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Web Application Security vulnerabilities detection

No description
by

DING YUE

on 15 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Web Application Security vulnerabilities detection

Web Application Security vulnerabilities detection
With the rapid economic development, Internet development is also expanding very fast. However, web security aspect is not improving at the same speed. Attacks from hackers and various virus threats are making the Internet environment more and more complicated. People are starting to consider the aspects of security on web applications. Research has been carried out and some new methods has been created to detect one of the main web application vulnerability (Cross-Site Scripting vulnerabilities ).
The reason for wanting to undertake this project is partly to further extend my knowledge in both PHP and web application security but also to try and understand and practice web application security skills. Hopefully web developers will also be able to develop websites with more focus on security aspects.
<1>. Aim and Purpose in the Plan


A1 Injection
A2 XSS
A3 Weak authentication and session management
A4 Insecure Direct Object Reference
A5 Cross Site Request Forgery
A6 Security Misconfiguration
A7 Insufficient Cryptographic Storage
A8 Failure to Restrict URL access
A9 Insufficient Transport Layer Protection
A10 Unvalidated Redirects and Forwards
The 10 most critical web application security risks
Currently, there are wide varieties of security vulnerabilities existing in web applications. The cause of the security threats is widely spread inside a variety of web application’s vulnerabilities. Web application vulnerability stems from negligence of a web developer where technical errors might exist on the website that can be used by an attacker to tamper with the security. Web applications are designed according to the rules of web developers, so once a vulnerability emerge and is exploited by an attacker, the original rules will change and make the web application run towards an unexpected state. The consequences can range from disclosure of sensitive information to causing the system to be completely incontrollable.
1.2 Aim and purpose
(1) Using PHP website design and implementation, to one step further improve the functionality of php programming.
(2) The PHP website, which I will create, will act as my experimental test object, to test the actual results of my research method.Rather than only create a PHP membership page for a local designer company, the idea of the project is to also detect security patterns of web applications.
The actual application that will be created is mainly a tool for being able to test my hypothesis.
1. PHP Relations Website Design and Implementation

The detection of web application vulnerabilities become more and more important. Web applications have been widely used in multiple businesses on the Internet while playing an increasingly important role. [1]However, various sorts of security vulnerabilities in web application greatly hinder web applications from flourishing. Therefore, adopting vulnerability detection to check whether web applications are vulnerable or not, is the key measure to enhance the security of web applications.
2. Detection of web application vulnerabilities
<2>. Currently finished work
research contents and methods
1.1 Background
The aim was by using PHP website which I will create act as my experimental object, to test the results of my web application vulnerabilities detection method. The actual application this project created is mainly a tool for being able test my vulnerabilities detection method will be improved some methods which are already
existing.

1. With the large number of web application emerging, security problem relating to web applications become increasingly prominent .
2. The attacker’s goal has begun to shift towards the user’s personal information stored in for instance a database. Especially in 2012, user information leakage events occurred frequently, for instance Linkedln, DropBox, Gamigo and other large company websites were hacked and had lots of their users personal information exposed. Those events shown us that current web applications are facing serious security threat.
Purpose of research
Current research situation
We have to have timely and effective detection of Web application vulnerabilities and then patch them as soon as possible.
Apply a new angle of detection methods to improve the effectiveness of web application’s detection of vulnerabilities.

Cross-site scripting vulnerabilities will arise if these four conditions are valid:
1. Untrusted data exists in the web application.
2. Untrusted data involved in the process of dynamic generated web application pages.
3. When the web application is in the process of generating the web
browser, it doesn’t filter out executable content, which due to malicious script is executed (These executable content include JavaScript,HTML,tags and attributes).
4. The browser which have been attacked perform malicious scripts in a contaminated page.
The reason to why SQL injection vulnerabilities occur is the external data affecting SQL query generation. According to some researchers related to SQL injection vulnerability studies,
SQL injection vulnerability detect methods can be divided into three categories:
1. Based on error SQL injection detection (Error-Based).
2.Based on boolean logic SQL injection detection (Boolean-Based).
3. Based on delay SQL blind injection detection (Time-Based).
<1>. Research background and propose
<2>. XSS vulnerabilities detection research
2.1 Definition of Cross-site scripting
Cross-site script will be caused because web applications haven’t been filtering correctly the users input when loading a website.

Most widely used vulnerability in a web attack. Most common Cross-site vulnerabilities occur when loading JavaScript. “Cross-site” means because of this vulnerability will send the malicious JavaScript user input go through the web application vulnerability till the web browser.

This will make the malicious JavaScript get permission to control all the resources in this domain area. The JavaScript can be able to cross the limitations of the domain to perform its script, thus it’s called Cross-site scripting.
2.2 The reasons of Cross-site scripting might be occur:
Cross-site scripting vulnerabilities will arise if the following four conditions are valid:
(1) Untrusted data enter into the web application.
(2) Untrusted data involved in the process of dynamic generated web application pages.
(3) When the web application is in the process of loading the web page, and it doesn’t filter out executable content, which can then due to malicious scripts get executed (These executable content include JavaScript, HTML, tags and attributes).
(4) The browser which have been attacked perform malicious scripts in a contaminated page.
2.3 Cross-site scripting vulnerabilities types
Cross-site script contains two main types: non-persistent (reflected) XSS and persistent (stored) XSS. Except these there is still one other special type, which is Cross-site script vulnerability based on DOM.
2.3.1 Reflected Cross-site script vulnerability
is the result of a Web application directly reading data from a HTTP request and placing it into the HTTP response. Because the victim and the user who is triggering are both the same body, the attacker would need to trick the user into triggering the vulnerability. This is shown in the diagram below:
2.3.2 Stored Cross-site script vulnerability
is caused by an attacker injecting malicious script in advance and stores it in a database. Whenever a user request a website, the script will be returned to the user and thus the malicious script will be performed by the user’s web browser. The difference between Stored type cross-site script and Reflected type cross-site script is whether or not a database has participated in the process where the vulnerability was generated.
The process of generate stored type cross-site script vulnerability
2.4 Damage of Cross-site script vulnerabilities
1. Lets attacker obtain permission to execute code in the web browser.
2. The attacker could be able to control the web browser and redirect the victim to malicious websites or phishing websites,that might lead to the attacker being able to steal the cookies or some login information that is stored in the web browser.

XXS worm has emerged on the Internet. Achieve self-replication and spreading. For instance, social networks. Cross-site script worms take the advantage of the user’s relative network to spread the malicious data.
<3>. SQL injection vulnerabilities
3.1 Definition of SQL injection vulnerabilities
Structured Query Language is the language dedicated using for queries, update and
manage database. When a web application receives user’s input to create part or all of
the SQL queries and no filtering or not properly filtered user input, this may modify
the meaning of the original SQL query and still send it to the database. This will trigger a SQL injection vulnerabilities.
3.2 There are five possible reasons to SQL injection vulnerability might occur:
(1) A user input untrusted data into a web application.
(2) Untrusted data takes part in the process of web application generated SQL query statements.
(3) The web application doesn’t filter out special characters in the process of generated SQL queries.
(4) The browser which have been attacked perform malicious SQL queries in the database query.
(5) The database performs unexpected commands in the process of analysisng SQL queries.
3.2.1 The process of generate SQL injection vulnerability
3.2.2 For instance, a simple ASP programming below using MySql database needs authentication of the user’s input, such as “username and password.
3.3 The damage of SQL injection vulnerabilities
1. Attacked database can be stolen, removed or modified. The serious problem will be the password that’s already stored in the database might get changed and this can lead to the web application not working as it should. An even more serious problem is that the web application’s server might be available to be manipulated by the attacker and the attacker could then modify the web application and perform malicious activities such as deploying a Trojan horse.

For instance, “Liza Moon”, just took a few days in order to take advantage of SQL injection vulnerabilities sweeping the whole world to attack over one million pages and left malicious code.
<4>. The Cross-site script vulnerabilities detection method
based on web browser
Cross-site script vulnerability detection methods will be improved regarding two
aspects:
designing a good monitoring sample
and
improve the vulnerability
distinguishing method
. In other words is to handle this problem by improving Attack Input and Responds Analysis. The method proposed is a Cross-site script vulnerability detection method: Add the web engine in the process of Response analysis to improve the accuracy of detection cross-site script vulnerability.
4.1 Reflected type Cross-site script
According to the mechanism of cross-site scripting, the process of Response analysis determines if the Reflecting type XXS exist depending on three identifiable conditions: reflective input parameters, the reflective integrity of the attack code and the performance ability of the attack code.
4.1.1 Reflective input parameters
Reflective input parameters means the value of the parameter entering the current monitoring entry point and being able to echo the user’s web browser. This is the prerequisite if reflective type XXS exists. If the condition is not met, then the
parameter is not reflective type XXS.
4.1.2 Reflective integrity of the attack code
To determine if this condition exists or not is based on if the attack code is changed or not after reflected. Because web applications usually have certain defensive mechanisms, so even if the attack code could be reflected, some of the key characters might have been filtered out and destroyed the original structure of the attack code.
4.1.3 Performance ability of the attack code
After determine the first two conditions, in order to reduce the rate of error informing, you need to ensure the attack code in the website can be executed by the web browser. The attacker cannot control the place where the attack code already had been reflected before. If the attack code is reflected into the data part of website, the attacker’s code will still not execute the code even if there still is some correctly structured attack code left.
4.2 Stored type Cross-site script

The generating of Stored type Cross-site script vulnerabilities are related to three layers in the Web application. They are the presentation layer, the logic layer and the data layer. The effect result cannot be retrieved immediately, thus the detection method becomes more complicated. There are two main problems:
4.3 The Cross-site scripting vulnerability that is based on the web browser engine

The browser engine is the core of the browser. By using the browser engine to monitor the behaviour of the web browser. For instance, to control the “alert” parameter of the pup-up window, using the parameter as a variable existing in the browser. This algorithm is using the browser engine to handle the response of web applications after the attack code has been injected. This is according to observe the change of the variable to make sure if the cross-site script really exist or not.
The import of the browser engine will eliminate the misstatement of cross-site scripting vulnerability detections. This can be done because the main purpose of detection cross-site script vulnerability lies in the browser’s behaviour. After the process of correctly monitoring the browser has finished, the detection will be able to eliminate the misstatement
1. The reflected type Cross-site scripting vulnerabilities detection algorithm that is based on the browser engine

Reflected cross-site script testing sample design
2. The stored type cross-site scripting vulnerabilities detection algorithm that is based on browser engine
Stored type cross-site scripting detection sample design
1. Response observation point is uncertain.
Because of the database take part in the generation of vulnerabilities, the entry and exit of parameters are usually not in the same position, which lead to that you cannot be certain where the attack code will appear again. Thus you cannot observe the response of the testing sample directly.

2. The persistent problem with the testing sample.
Because parts of the testing attack code will remain in the web application when Stored type Cross-site script triggers successfully, it will damage the web application. Therefore, an attack of serious harm cannot be used as an attack sample.
According to the theory of generation of reflected cross-site scripting vulnerability, we can divide the testing samples into two parts, based on integrity label testing samples and also based on event trigger testing samples.

(1) Based on integrity tag testing sample design
This type of testing includes a completed HTML tag. In the tag, insert a JavaScript, such as “<script> alert (‘XSS’)</script>”. Thus far, we have determined two basic type of testing example. Based on these two testing sample we can do some improvements. The main point is to avoid the defensive mechanisms of web applications, such as: add a HTML close up tag in front of the testing sample. Capital and lower case letters transfer and also ASCII encoding conversion. The final determined testing sample is as the following:
(2) Base on event triggering testing sample
This type of testing sample setting is to use for handling the reflected cross-site scripting detection principle, in the reflected code down to the HTML data area that is fetched by the enforceability part of attacking code. This type of testing sample sets the form to: “ “ onload=”alert(‘XXS’)” ” ”. The purpose of this is to use double or single quotes to advance close the default property data area, so that interpretation of the data behind to HTML code….
The flow chart of reflected XXS detection algorithm.

Stored type cross-site scripting detection sample design
In the process of detecting reflected XXS vulnerabilities, we will be using the alert
function. If we are in the process of detecting stored XXS vulnerabilities using “alert”,
the pup-up windows will appear once a user trigger the vulnerability successfully. To minimize web application security testing from the testing damage, we also need to take into account the need for vulnerability detection at same time. This project is using the method called “document.write” as a JavaScript testing sample. For instance, <script>document.write(a+b)</script>, a and b are two random long number. The successful result of the detection will be shown “a+b” result on the website. If we can detect the result number of “a+b” in the website, then we can determine if the load has been successfully performed. First inject the testing sample to all the parameter entries and then traversal the web application. If the testing sample result is localized, then it means that the stored XXS has been found. Thereby, it also solves the problem with localization response observation point.
Stored type XXS detection method flowchart
4.3 The Cross-site scripting vulnerability that is based on the web browser engine
The project designs a Cross-site scripting module where the main structure will be like the diagram below:
XSS Implementation
Programming language:
python
Programming environment:
Eclipse (Installation and Configuration "
pydev
" plugin)+
pyqt
(a tool widely used to create GUI app ) +
lxml
(analysis xml programming )
Testing Object: PHP website or WackoPicko

https://github.com/adamdoupe/WackoPicko
Things to do in the near future
Full transcript