Xx_Menu
- SSL:request https
- CA certificate install
- CA certificate remove - advanced options
- Proxy Listence configuration
- SSL direct connect and contact agent
Ax_CA certification install
z.open http://burp download CA certificate
y.Configurate CA certification
open Internet explorer
Alt+x
o
[Contact]
C
Bx_CA certification remove
You can..
Or..
cmd
mmc
Control + M
Cx_Proxy Listence configuration
First:Burp Suite default listence port 8080, but we need to test different applications.z.Proxy listence configuration
y./add/
x.Proxy introduction
Binding These settings control how Burp binds the Proxy listener to a local network interface:- Bind to port - This is the port on the local interface that will be opened to listen for incoming connections. You will need to use a free port that has not been bound by another application.
- Bind to address - This is the IP address of the local interface that Burp will bind to. You can bind to just the loopback interface, or to all interfaces, or to any specific local IP address. Note: if the listener is bound to all interfaces or to a specific non-loopback interface, then other computers may be able to connect to the listener. This may enable them to initiate outbound connections originating from your IP address, and to access the contents of the Proxy history, which may contain sensitive data such as login credentials. You should only enable this when you are located on a trusted network.
- Redirect to host - If this option is configured, Burp will forward every request to the specified host, regardless of the target requested by the browser. Note that if you are using this option, it may be necessary to configure a match/replace rule to rewrite the Host header in requests, if the server to which you are redirecting requests expects a Host header that differs from the one sent by the browser.
- Redirect to port - If this option is configured, Burp will forward every request to the specified port, regardless of the target requested by the browser.
- Force use of SSL - If this option is configured, Burp will use HTTPS in all outgoing connections, even if the incoming request used plain HTTP. You can use this option, in conjunction with the SSL-related response modification options, to carry out sslstrip-like attacks using Burp, in which an application that enforces HTTPS can be downgraded to plain HTTP for a victim user whose traffic is unwittingly being proxied through Burp.
- You can eliminate SSL alerts in your browser, and the need to create SSL exceptions.
- Where web pages load SSL-protected items from other domains, you can ensure that these are properly loaded by the browser, without the need to first manually accept the proxy's SSL certificate for each referenced domain.
- You can work with thick client applications that refuse to connect to the server if an invalid SSL certificate is received. The following options are available:
- Use a self-signed certificate - A simple self-signed SSL certificate is presented to your browser, which always causes an SSL alert.
- Generate CA-signed per-host certificates - This is the default option. Upon installation, Burp creates a unique, self-signed Certificate Authority (CA) certificate, and stores this on your computer to use each time Burp is run. When your browser makes an SSL connection to a given host, Burp generates an SSL certificate for that host, signed by the CA certificate. You can install Burp's CA certificate as a trusted root in your browser, so that the per-host certificates are accepted without any alerts. You can also export the CA certificate to use in other tools or other instances of Burp.
- Generate a CA-signed certificate with a specific hostname - This is similar to the preceding option; however, Burp will generate a single host certificate to use with every SSL connection, using the hostname you specify. This option is sometimes necessary when performing invisible proxying, because the client does not send a CONNECT request, and so Burp cannot identify the required hostname prior to the SSL negotiation. As previously, you can install Burp's CA certificate as a trusted root.
- Use a custom certificate - This option enables you to load a specific certificate (in PKCS#12 format) to present to your browser. This option should be used if the application uses a client which requires a specific server certificate (e.g. with a given serial number or certification chain).
Dx_SSL direct connect and contact agent
z.intro:
These settings are used to specify destination webservers for which Burp will directly pass through SSL connections. No details about requests or responses made via these connections will be available in the Proxy intercept view or history.
Passing through SSL connections can be useful in cases where it is not straightforward to eliminate SSL errors on the client - for example, in mobile applications that perform SSL certificate pinning. If the application accesses multiple domains, or uses a mix of HTTP and HTTPS connections, then passing through SSL connections to specific problematic hosts still enables you to work on other traffic using Burp in the normal way.
If the option to automatically add entries on client SSL negotiation failure is enabled, then Burp will detect when the client fails an SSL negotiation (for example, due to not recognizing Burp's CA certificate), and will automatically add the relevant server to the SSL pass through list.
y.contact agent
- configuration hosts file
- Windows==> C:/Windows/System32/drivers/etc/hosts
- Linux==> /etc/hosts
- add==> 127.0.0.1 example.com
- add proxy listence and port 80,if https need add CA certification and port 443
target of forward truth server
Ex_How to use /Burp Target/ and /Burp Spider/
be continued..
