Monday, June 16, 2014

Introduction Burp Suite Part III ( Spider Tab)


Burp Spider is a tool for automatically crawling web applications. You can use this in conjunction with manual mapping techniques to speed up the process of mapping an application's content and functionality.

Spider Status
Use these settings to monitor and control Burp Spider:
 Spider is paused / running - This toggle button is used to start and stop the Spider. While the Spider is stopped it will not make any requests of its own, although it will continue to process responses generated via Burp Proxy (if passive spidering is enabled), and any newly-discovered items that are within the spidering scope will be queued to be requested if the Spider is restarted.
Clear queues - If you want to reprioritize your work, you can completely clear the currently queued items, so that other items can be added to the queue. Note that the cleared items may be re-queued if they remain in-scope and the Spider's parser encounters new links to the items.
The display also shows some metrics about the Spider's progress, enabling you to see the size of the in-scope content and the work remaining to fully spider it.




Spider Scope
 This panel lets you define exactly what is in-scope for the Spider to request.
 The best way to handle spidering scope is normally using the suite-wide target scope, and by default the Spider will use that scope. If you need to define a different scope for the Spider to use, then select "Use custom scope". A further configuration panel will appear which functions in the same way as the suite-wide target scope panel. If you have selected to use a custom scope and you send any out-of-scope items to the Spider, then Burp will automatically update this custom scope, rather than the Suite scope.
(Click image for large view)


Spider Options
This tab contains options for the basic crawler settings, passive spidering, form submission, application login, the Spider engine, and HTTP request headers.

Crawler Settings
These settings control the way the Spider crawls for basic web content:
  • Check robots.txt - If this option is checked, the Spider will request and process the robots.txt file, to extract links to content. This file is used by the robots exclusion protocol to control the behavior of spider-like agents on the Internet. Note that the Spider does not conform to the robots exclusion protocol. Because the Spider is designed to enumerate a target application's content, all entries in robots.txt will be requested if they are in scope.
  • Detect custom "not found" responses - The HTTP protocol requires web servers to return a 404 status code if a requested resource does not exist. However, many web applications return customized "not found" pages that use a different status code. If this is the case, then using this option can prevent false positives in the mapping of site content. Burp Spider detects custom "not found" responses by requesting several nonexistent resources from each domain, and compiling a fingerprint with which to diagnose "not found" responses to other requests.
  • Ignore links to non-text content - It is often possible to deduce the MIME type of a particular resource from the HTML context in which links to it appear (for example <img> tags). If this option is checked, the Spider will not request items which appear, from this context, to be non-text resources. Using this option can reduce spidering time with minimal risk of overlooking interesting content as a result.
  • Request the root of all directories - If checked, the Spider will request all identified web directories within the target scope, in addition to files within those directories. This option is particularly useful if directory indexing is available on the target site.
  • Make a non-parameterized request to each dynamic page - If checked, the Spider will make a non-parameterized GET request to all in-scope URLs that accept query string parameters. Dynamic pages usually respond differently if the expected parameters are not received, and this option may successfully detect additional site content and functionality.
  • Maximum link depth - This is the maximum number of "hops" that the Spider will navigate from any seed URL. A value of zero will cause the Spider to request seed URLs only. If a very large number is specified, then in-scope links will be followed effectively indefinitely. Setting this option to a reasonable number can help to prevent spidering loops in certain kinds of dynamically generated content.
  • Maximum parameterized requests per URL - This is the maximum number of requests that the Spider will make to the same base URL with different parameters. Setting this option to a reasonable number can help to avoid crawling "infinite" content, such as calendar applications with a date parameter in the URL.

     Passive Spidering
     Passive spidering monitors traffic through Burp Proxy to update the site map without making any new requests. This enables you to map out an application's content and functionality in a very controlled way using your browser.

    The following options are used to control passive spidering: 
    • Passively spider as you browse - If checked, Burp Spider will process all HTTP requests and responses made through Burp Proxy, to identify links and forms on pages that you visit. Using this option can enable Burp to build up a detailed picture of an application's content even when you have only browsed a subset of that content, because Burp identifies everything that is linked from the content that you do browse. Content that you have requested is shown in black on the Target site map, while unrequested content is shown in gray, enabling you to easily identify areas of the application that require further mapping.
    • Link depth to associate with Proxy requests - This option controls the "link depth" which will be associated with URLs accessed through Burp Proxy.
    Form Submission
      These settings control whether and how the Spider submits HTML forms. Simply following linked URLs will achieve limited coverage of most applications. To discover all of an application's content and functionality, it is generally necessary to submit forms using realistic inputs.

    The following options are available: 
    • Individuate forms - This option configures the criteria for individuating unique forms (action URL, method, fields, values). When the Spider processes each form, it will check these criteria to determine if the form is "new". Forms that are new will be queued for submission, according to the other form submission options. Careful use of this option can help the Spider to deal with applications that make use of different forms-based navigational structures.
    • Don't submit forms - If selected, the Spider will not submit any forms.
    • Prompt for guidance - If selected, the Spider will prompt you for guidance before submitting each form. The interactive prompt allows you to enter custom data into form input fields as required, select which submit fields to send to the server, and choose whether to iterate through all available submit fields.
    • Automatically submit - If selected, the Spider will automatically submit any in-scope forms using the defined rules to assign the values of text input fields. Each rule lets you specify a simple or regular expression to match on form field names, and the value to submit in fields whose names match the expression. A default value can be specified for any unmatched fields.
    This option is particularly useful if you want to automatically spider through registration forms and similar functions, where applications typically require data in a valid format for each input field. Burp comes with a set of default rules that have proven successful when automatically submitting form data to a wide range of applications. You can modify these or add your own rules if you encounter form field names that you want to submit specific values in. You should use this option with caution, as submitting bogus values in forms may sometimes result in undesirable actions.
    Many forms contain multiple SUBMIT elements, which result in different actions within the application, and the discovery of different content. You can configure the Spider to iterate through the values of all submit elements within forms, submitting each form multiple times up to a configurable maximum.

    Application Login
     These settings control how the Spider submits login forms.
     Because of the function that authentication plays in web applications, you will often want Burp to handle login forms in a different way than ordinary forms. Using this configuration, you can tell the Spider to perform one of four different actions when a login form is encountered:
    • Burp can ignore the login form, if you don't have credentials or are concerned about spidering sensitive protected functionality.
    • Burp can prompt you for guidance interactively, enabling you to specify credentials on a case-by-case basis. This is the default option.
    • Burp can handle login forms in the same way as any other form, using the configuration and auto-fill rules you have configured for those.
    • Burp can automatically submit specific credentials in every login form that is encountered. When Burp tries to do this, it will submit your configured password in the password field, and will submit your configured username in the text input field whose name most looks like a username field.
    Note that you can also use the suite-wide session handling rules to deal with authentication while performing automated spidering. If you use session handling rules to maintain a valid session with the application, then you should configure the Spider not to submit login forms, to avoid disrupting your session.

    Spider Engine
     These settings control the engine used for making HTTP requests when spidering. The following options are available: 
    • Number of threads - This option controls the number of concurrent requests the Spider is able to make.
    • Number of retries on network failure - If a connection error or other network problem occurs, Burp will retry the request the specified number of times before giving up and moving on. Intermittent network failures are common when testing, so it is best to retry the request several times when a failure occurs.
    • Pause before retry - When retrying a failed request, Burp will wait the specified time (in milliseconds) following the failure before retrying. If the server is being overwhelmed with traffic, or an intermittent problem is occurring, it is best to wait a short time before retrying.
    • Throttle between requests - Optionally, Burp can wait a specified delay (in milliseconds) before every request. This option is useful to avoid overloading the application, or to be more stealthy.
    • Add random variations to throttle - This option can further increase stealth by reducing patterns in the timing of your requests.
    Careful use of these options lets you fine tune the spidering engine, depending on the performance impact on the application, and on your own processing power and bandwidth. If you find that the Spider is running slowly, but the application is performing well and your own CPU utilization is low, you can increase the number of threads to make your spidering proceed faster. If you find that connection errors are occurring, that the application is slowing down, or that your own computer is locking up, you should reduce the thread count, and maybe increase the number of retries on network failure and the pause between retries.

    Request Headers
     These settings control the request headers used in HTTP requests made by the Spider.
     You can configure a custom list of headers to be used in Spider requests. This may be useful to meet specific requirements of individual applications - for example, to emulate an expected user agent when testing applications designed for mobile devices.

    The following options are also available: 
    • Use HTTP version 1.1 - If checked, the Spider will use version 1.1 of HTTP in its requests; otherwise, it will use version 1.0.
    • Use Referer header - If checked, the Spider will submit the relevant Referer header when requesting any item that was linked to from another page. This option is useful to more closely simulate the requests that would be made by your browser, and may also be necessary to navigate through some applications that validate the Referer header.
    (Click image for large view)
    Like it ? Share it.

    Saturday, June 14, 2014

    Windows Web Hosting

    The availability of Microsoft’s Active Server Pages technology in Windows hosting solutions provides for dynamic web pages that can help give your website the best possible presentation and performance.  ASP is a powerful and flexible technology that can provide your site users with a range of interactive page options and functionality that surpasses the norm.  When opting for a Windows hosting package equipped with this dynamic programming technology, you will then have the tools needed to gain an edge on the competition.

    If I use Windows Hosting, is it necessary my operating system should be Windows?
    The answer is NO. The type of hosting you choose has nothing to do with the operating system your PC runs.



    Below are some features which provided by WebHosting Companies:

    Statistics
    This is where you view detailed reports on how resources provided with your subscription are used.

    File Manager
    Upload new files and work with current files and directories of your websites.

    Web Statistics
    View the reports on how your websites are visited. See how many people visited a site and which webpages they viewed.

    FTP Access
    Set up access to files of your websites over FTP protocol.

    DNS Setting
    Mangage DNS zone for your Domain names.

    Backup Manager
    Back Up and restore your domains, including settings and content of websites and mail accounts.

    Web Hosting Access
     Change setting of the system user account used for remote access to Panel over SSH or RDP and working with files and folders in File Manager.

    Databases
    Create and remove databases used by your websites and manage them using integrated administrative web application.

    Password Protected Directories
    Restrict access to selected areas of your website with password protection.

    Website Copying
    Copy website files to another site or external FTP Storage.

    Logs
    View logs and configure recycling of logs files.

    Dedicated IIS Application Pool for your Websites
    Set Up a dedicated IIS application pool for serving website associated with the currently selected subscription.

    ASP.NET Setting
    Configure the setting of ASP.NET framework.

    Scheduled Tasks
    View and Manage scheduled tasks.

    Hotlink Protection
    Protect content of your websites from hotlilnking.

    Web Users
    Set up accounts for users who can host personal web pages on your websites.

    Website Maintenance Mode
    Switch a site off for maintenance and let the site visitors know that this is done on purpose and the site will be up soon.

    Virtual Directories
    Create and manage virtual directories for your websites.

    ODBC Data Sources
    Set up ODBC Data sources.

    Note - Above Features list are just an example. May be you will get more features or less features its depend on the hosting provider companies. Some webhosting also provides some software and services.

    Like it ? Share it.

    Wednesday, June 11, 2014

    Introduction Burp Suite Part II ( Proxy Tab)


    Burp Proxy lies at the heart of Burp's user-driven workflow. It operates as a web proxy server between your browser and target applications, and lets you intercept, inspect and modify the raw traffic passing in both directions.
    If the application employs HTTPS, Burp breaks the SSL connection between your browser and the server, so that even encrypted data can be viewed and modified within the Proxy.


    1. Intercepting
          The Intercept tab is used to display and modify HTTP and WebSockets messages that pass between your browser and web servers. When an intercepted message is being displayed, details of the destination server are shown at the top of the panel. For HTTP requests, you can manually edit the target server to which the request will be sent, by clicking on the server caption or the button next to it.
    Forward- When you have reviewed and (if required) edited the message, click "Forward" to send the message on to the server or browser.
    Drop- Use this to abandon the message so that it is not forwarded.
    Interception is on/off - This button is used to toggle all interception on and off. If the button is showing "Intercept is on", then messages will be intercepted or automatically forwarded according to the configured options for interception of HTTP and WebSockets messages. If the button is showing "Intercept is off" then all messages will be automatically forwarded.
    Action- This shows a menu of available actions that can be performed on the currently displayed message. These are the same options that appear on the context menu of the intercepted message display.
    Comment field - This lets you add a comment to interesting items, to easily identify them later. Comments added in the intercept panel will appear in the relevant item in the Proxy history. Further, if you add a comment to an HTTP request, the comment will appear again if the corresponding response is also intercepted.
    Highlight- This lets you apply a colored highlight to interesting items. As with comments, highlights will appear in the Proxy history and on intercepted responses.
    (Click image for large view)


    2. History
          The Proxy history maintains a full record of all messages that have passed through the Proxy. You can filter and annotate this information to help manage it. The Proxy history is always updated even when you have interception turned off, allowing you to browse without interruption while still monitoring key details about application traffic.
    History Table
    Separate history tables are shown for HTTP and WebSockets messages. Each table shows full details of the messages that have passed through the Proxy, and any modifications you have made to intercepted messages.
    The HTTP history table contains the following columns: 
    • The request index number
    • The protocol and server hostname
    • The HTTP method
    • The URL file path and query string
    • Flag whether the request contains any parameters
    • Flag whether the request or response were modified by the user
    • The HTTP status code of the response
    • The length of the response in bytes
    • The MIME type of the response
    • The URL file extension
    • The page title (for HTML responses)
    • Any user-applied comment
    • Flag whether SSL is used
    • The IP address of the destination server
    • Any cookies that were set in the response
    • The time the request was made
    • The listener port on which the request was received
    3. Option
         This tab contains Burp Proxy settings for Proxy listeners, intercepting HTTP requests and responses, intercepting WebSockets messages, response modification, match and replace, SSL pass through, and miscellaneous options.

    A. Proxy Listeners
         A Proxy listener is a local HTTP proxy server that listens for incoming connections from your browser. It allows you to monitor and intercept all requests and responses. By default, Burp creates a single listener on port 8080 of the loopback interface. To use this listener, you need to configure your browser to use 127.0.0.1:8080 as its proxy server. Visit Configure Browser
    Burp lets you create multiple Proxy listeners, and provides a wealth of configuration options for controlling their behavior. You may occasionally need to use these options when testing unusual applications, or working with some non-browser-based HTTP clients. 

    B. Intercepting HTTP Requests and Responses
        These settings control which requests and responses are stalled for viewing and editing in the Intercept tab. Separate settings are applied to requests and responses.
    The "Intercept" checkbox determines whether any messages are intercepted. If it is checked, then Burp applies the configured rules to each message to determine whether it should be intercepted.
     Individual rules can be activated or deactivated with the checkbox on the left of each rule. Rules can be added, edited, removed, or reordered using the buttons.
     Rules can be configured on practically any attribute of the message, including domain name, IP address, protocol, HTTP method, URL, file extension, parameters, cookies, header/body content, status code, MIME type, HTML page title, and Proxy listener port. You can configure rules to only intercept items for URLs that are within the target scope. Regular expressions can be used to define complex matching conditions for each attribute.
     Rules are processed in order, and are combined using the Boolean operators AND and OR. These are processed with a simple "left to right" logic in which the scope of each operator is as follows:
     (cumulative result of all prior rules) AND/OR (result of current rule)
    All active rules are processed on every message, and the result after the final active rule is applied determines whether the message is intercepted or forwarded in the background.
    The "Automatically update Content-Length" checkbox controls whether Burp automatically updates the Content-Length header of the message when this has been modified by the user. Using this option is normally essential when the HTTP body has been modified.
    For requests, there is an option to automatically fix missing or superfluous new lines at the end of requests. If an edited request does not contain a blank line following the headers, Burp will add this. If an edited request with a body containing URL-encoded parameters contains any newline characters at the end of the body, Burp will remove these. This option can be useful to correct mistakes made while manually editing requests in the interception view, to avoid issuing invalid requests to the server.

    C. Response Modification
           These settings are used to perform automatic modification of responses. You can use these options to achieve various tasks by automatically rewriting the HTML in application responses.
     The following options may be useful to remove client-side controls over data:
    • Unhide hidden form fields. (There is a sub-option to prominently highlight unhidden fields on-screen, for easy identification.)
    • Enable disabled form fields
    • Remove input field length limits
    • Remove JavaScript form validation
    The following options may be useful for disabling client-side logic for testing purposes (note that these features are not designed to be used as a security defense in the manner of NoScript): 
    • Remove all JavaScript
    • Remove <object> tags
    The following options may be used to deliver sslstrip-like attacks against a victim user whose traffic is unwittingly being proxied via Burp. You can use these in conjunction with the listener option to force SSL in outgoing requests to effectively strip SSL from the user's connection: 
    • Convert HTTPS links to HTTP
    • Remove secure flag from cookies
    D. Match and Replace
           These settings are used to automatically replace parts of requests and responses passing through the Proxy. For each HTTP message, the enabled match and replace rules are executed in turn, and any applicable replacements are made.
     Rules can be defined separately for requests and responses, for message headers and bodies, and also specifically for the first line only of requests. Each rule can specify a literal string or regex pattern to match, and a string to replace it with.
     For message headers, if the match condition matches the entire header and the replacement string is left blank, then the header is deleted. If a blank matching expression is specified, then the replacement string will be added as a new header.
     There are various default rules available to assist with common tasks - these are disabled by default.


    E. Miscellaneous
          These settings control some specific details of Burp Proxy's behavior. The following options are available:
    • Use HTTP/1.0 in requests to server - This option controls whether Burp Proxy enforces HTTP version 1.0 in requests to destination servers. The default setting is to use whichever version of HTTP is used by the browser. However, some legacy servers or applications may require version 1.0 in order to function correctly.
    • Use HTTP/1.0 in responses to client - All current browsers support both version 1.0 and 1.1 of HTTP. Since version 1.0 has a reduced feature set, forcing use of version 1.0 can sometimes be useful to control aspects of browsers' behavior, such as preventing attempts to perform HTTP pipelining.
    • Set response header "Connection: close" - This option may also be useful to prevent HTTP pipelining in some situations.
    • Unpack gzip / deflate in requests - Some applications (often those using custom client components), compress the message body in requests. This option controls whether Burp Proxy automatically unpacks compressed request bodies. Note that some applications may break if they expect a compressed body and the compression has been removed by Burp.
    • Unpack gzip / deflate in responses - Most browsers accept gzip- and deflate-compressed content in responses. This option controls whether Burp Proxy automatically unpacks compressed response bodies. Note that you can often prevent servers from attempting to compress responses by removing the Accept-Encoding header from requests (possibly using Burp Proxy's match and replace feature).
    • Disable web interface at http://burp - This option may be useful if you are forced to configure your listener to accept connections on an unprotected interface, and wish to prevent others gaining access to Burp's in-browser controls.
    • Suppress Burp error messages - When certain errors occur, by default Burp returns meaningful error messages to the browser. If you wish to run Burp in stealth mode, to perform man-in-the-middle attacks against a victim user, then it may be useful to suppress these error messages to disguise the fact that Burp is involved.
    • Disable logging to history and site map - This option prevents Burp from logging any requests to the Proxy history or the target site map. It may be useful if you are using Burp Proxy for some specific purpose, such as authenticating to upstream servers or performing match-and-replace operations, and you want to avoid incurring the memory and storage overhead that logging entails.
    • Enable interception at startup - This option lets you configure whether Proxy interception should be enabled when Burp is started up. You can choose to always enable interception, always disable interception, or to restore the setting from when Burp was last closed.
    (Click image for large view)

    Like it ? Share it.

    Sunday, June 8, 2014

    Apps To Track Lost / Stolen Android Devices

    If you have forget your android while travelling or someone stolen your android mobile phone you do not need to worry if you have one of these application installed in your device. You can track your mobile phone with the apps term and condition. I like to advice within purchasing your Android mobile install these awesome apps for protecting your device.

    Where’s My Droid
    Where’s My Droid is a pure Find my Phone app to help you locate your phone. When your smartphone goes missing, sending a code via text will make the phone ring (even when set in silent mode) while another text code sends you the GPS coordinates of the phone. Alternatively, you can remotely control your phone by connecting it to the Commander option, a web-based interface. Where’s My Droid also offers a Pro version which lets you take pictures with the camera (you might be able to take a snapshot of the perpetrator), remote lock the phone rendering it impenetrable or remote wipe the app to save your data from misuse.

    Plan B
    If you had not install any tracking app before your Android device was stolen or misplaced, Plan B will be a lifesaver. Plan B is an Android app from Lookout Labs which locates your smartphone using cell towers and GPS, then sends the location of your smartphone to your Gmail Inbox. In some smartphones, Plan B can enable the GPS on the phone then update you with its location every 10 minutes. For phones with no such support, you can text ‘location’ from another phone, and details of the missing phone’s location will be sent to your email. In the absence of a data connection, the software will send its location via SMS instead.



    Lookout Security Anti-Theft
    Lookout Security & Antivirus gives Android users peace of mind keeping phones and tablets safe and secure. By going to lookout.com, users can find their lost device on a Google Map, have their device make a loud noise even if it’s on silent, or if their battery dies, users can see the last location where they had their device. If someone tries to steal or unlock your device, you’ll receive an email with the picture and location info of the person who tries to steal it. Lookout Security & Antivirus will protect all your personal data so know one sees it.

    Seek Droid
    Seek Droid is an app that lets users find their Android phone or tablet. Users can locate their phone using GPS and find the accurate location, and it will be placed on Google Maps. Other features include being able to lock the phone, wipe, it, or wipe the SD.

    Android Lost Free
    This app is not only perfect for finding your lost phone, it will also torment the thief (something which we’re sure they fully deserve). You can activate (via SMS or the Web) the alarm to ring with a flashing screen, enable and disable the GPS, data and Wi-Fi connection, remote wipe the SD card, and get their latest call list.Once the SIM card is changed, you will be informed via email. This app can be used even after you have lost your smartphone due to its remote install feature and is hidden from the launcher to prevent uninstallation.

    Prey Anti-Theft
    Prey is an anti-theft app developed by Fork Ltd. Prey lets users track and locate a lost or stolen Android phone. Users will receive detailed reports on who has their device and where they can find it. Lock your device and trigger the alarm even if your phone is on silent.

    Bitdefender Anti-Theft
    Bitdefender is an anti-theft app developed by Bitdefender. Bitdefender Mobile security blocks the latest malware, spyware, Trojans, and other threats. Misplaced or stolen phone? Send SMS commands, lock, geo-locate, sound an alarm, and wipe your Android device from any internet connection.

    McAfee Antivirus & Security
    It comes as a 7-day free trial but to keep it on your phone, it’s a $30/year subscription. For that sum, you get the regular anti-theft protection, antivirus protection, plus data backup and restore functions.

    AVG AntiVirus
    It can locate your lost or stolen phone via Google Maps and lock your device to protect your privacy via a text message. If your phone or tablet is stolen or missing, you can also set a lock screen message to help the locator find you and make your device ring even when it’s on silent mode.

    Like it ? Share it.

    Monday, June 2, 2014

    Introduction Burp Suite Part I (Burp Suite Target Tab)


    Topic - In this Article we will learn Burp Suite's Target Tab. You will see how Target Tab is most important part of burp suite.
    Requirement:
    B. Firefox or iceweasel
    C. Burp Suite (We are using Free Version)



    1. Each time whenever you need to perform Mutillidae in your system, you have to run mysql and apache server.
    Open Terminal
        a. Type service mysql start and Press Enter
        b. Type service apache2 start and Press Enter
    Both servers have been started. Now, you can open mutillidae without any issue.
    Before opening Mutillidae Lets start Burp Suite. In Terminal type burpsuite.jar and Press Enter.
     (Click image for large view)


    2. Your burp suite has been started. First of all turn off intercept. We will discuss about it later because in this article we will discuss only about Target Tab.

    3. Open your Internet Browser and browse your Mutillidae as per your setup. If you have installed and configured Mutillidae according to my article then type 127.0.0.1/mutillidae in the browser web address and search it. Soon you will get your Mutillidae screen.

    4. Target tab contains detailed information about your target applications, and lets you drive the process of testing for vulnerabilities.
    Site Map Sub-tab
        A. The site map contains all of the URLs you have visited in your browser, and also all of the content that Burp has inferred from responses to your requests. Items that have been requested are shown in black, and other items are shown in gray. You can expand branches in the tree, select individual items, and view the full requests and responses. The tree view contains a hierarchical representation of content, with URLs broken down into domains, directories, files, and parameterized requests. You can expand interesting branches to see further detail. If you select one or more parts of the tree, all the selected items and items in child branches are shown in the table view.
          B. The table view shows key details about each item (URL, HTTP status code, page title, etc.).
          C. Request and Response Pane

    5. If you select an item in the table, the request and response for that item are shown in the request/response pane.
    Request Tab
          Raw – You can see host, user agent, server and cookies etc.

    6. Request Tab
          Params – As you can see it shows cookies.

    7. Request Tab
          Headers – Its look like raw details but in well organized. This shows headers details.

    8. Request Tab
          Hex – It shows details like host user etc in hex code.

    9. Response Tab
          Raw – This is what server responding, Raw sub-tab shows server details etc. If you will scroll down you will notice HTML codes are there but leave it for now because there are HTML sub-tab has given separately.

    10. Response Tab
          Headers – Organized details of respond server.

    11. Response Tab
          Hex – Details in Hex.

    12. Response Tab
          HTML – In this section we can see respond html codes.

    13. Response Tab
          Render – Render shows the actually view of the site how it looks like exactly.

    14. Scope Sub-tab - The scope configuration tells Burp the items that you are currently interested in and willing to attack. The scope definition uses two lists of URL-matching rules - an "include" list and an "exclude" list. When Burp evaluates a URL to decide if it is within the target scope, it will be deemed to be in scope if the URL matches at least one "include" rule and does not match any "exclude" rules. This enables you to define specific hosts and directories as being generally within scope, and yet exclude from that scope specific subdirectories or files (such as logout or administrative functions). You can add or edit rules on the "include" and "exclude" lists using the URL-matching rule editor.
    Each URL-matching rule can specify various features of the URLs that will be matched. For a URL to match the rule, it must match all of the features that are specified by the rule. The following items can be configured:
    Protocol - This specifies the protocol(s) that the rule will match. Available options are: HTTP, HTTPS, or any.
    Host or IP range - This specifies the host(s) that the rule will match. You can enter a regular expression to match the hostname, or an IP range in various standard formats, for example 10.1.1.1/24 or 10.1.1-20.1-127. If the host field is left blank, then the rule can match URLs containing any host.
    Port - This specifies the port(s) that the rule will match. You can enter a regular expression to match one or more port numbers. If the port field is left blank, then the rule can match URLs containing any port.
    File - This specifies the file portion of the URL that the rule will match (ignoring any query string). You can enter a regular expression to match the required range of URL files. If the file field is left blank, then the rule can match URLs containing any file.
    However, in most cases, by far the easiest way to define your target scope is via the site map. As you map out the target application via Burp Proxy, the application's content will appear in the site map. You can then select one or more hosts and folders, and use the context menu to include or exclude these from the scope. This process is extremely easy and in most situations will let you quickly define all of the rules necessary for your testing.

    15. Context Menu - Displaying all of the information gathered about your target, the site map enables you to control and initiate specific attacks against the target, using the context menus that appear everywhere. The exact options that are available depend on the location where the context menu was invoked, and the type of item selected. The complete list of context menu actions is as follows:
    Add to / remove from scope - These options create new target scope rules which add or remove the selected item from scope. The rule generated will apply to the selected item and all child branches in the tree. A common technique when testing an application that includes some sensitive URLs is to add the whole application path (domain or directory) to the target scope, and then select the sensitive items and exclude them from scope.
    Spider this host- You can select a host or folder within the tree view, and perform actions on the entire branch of the tree, such as spidering.
    Actively scan this host- [Pro version] Actively scan takes an individual request to the application, called the "base request", and modifies it in various ways designed to trigger behavior that indicates the presence of various vulnerabilities. These modified requests are sent to the application, and the resulting responses are analyzed. In many cases, further requests will be sent, based on the results of the initial probes. You should use this scanning mode with caution, only with the explicit permission of the application owner, and having warned them of the possible effects that automated scanning may have on the application and its data.
    Passively scan this host- [Pro version] Passively scanning doesn't send any new requests to the application - it merely analyzes the contents of existing requests and responses, and deduces vulnerabilities from those. This mode of operation can be used safely and legally in any situation in which you are authorized to access the application.
    Engagement tools- [Pro version] This submenu contains various useful functions for carrying out engagement-related tasks:
          Search - [Pro version] You can use the Search function to search the selected branches of the site map for items matching a specific expression.
         Find comments / scripts - [Pro version] You can use the Find comments / scripts functions to search the selected branches of the site map for comments and scripts.
         Find references - [Pro version] You can use the Find references function to search all of Burp's tools for HTTP responses that link to the selected item.
         Analyze target - [Pro version] You can use the Target Analyzer function to analyze the selected branches of the site map and tell you how many static and dynamic URLs it contains, and how many parameters each URL takes.
        Discover content - [Pro version] You can use the Discover content function to discover content and functionality that is not linked from visible content which you can browse to or spider.
        Schedule task - [Pro version] You can use the Schedule task function to create tasks that will run automatically at defined times and intervals.
        Simulate manual testing - [Pro version] The Manual testing simulator can be used to generate HTTP traffic that is similar to that caused by manual penetration testin
    Compare site maps- You can use the Compare site maps function to identify differences between two site maps. This is a powerful feature that can be used for various purposes, in particular testing for access control vulnerabilities.
    Expand / collapse branch / requested items - You can use these functions in the tree view to quickly expand whole branches of the tree, and collapse them after you have reviewed them.
    Delete host- This function removes the selected item permanently. Since by default the site map displays all content that Burp has identified based on HTTP responses, the map will often include a large amount of third-party content that is linked to from the application you are interested in. You can deal with this either by configuring a suitable target scope and a display filter, or by manually removing irrelevant branches of the tree.
    Copy URLs in the host- This function copies the URLs of the selected item to the clipboard.
    Copy links in the host- This function parses the selected item for links, and copies these to the clipboard.
    Save selected items- This function lets you specify a file to save the details of selected item in XML format, including full requests and responses, and all relevant metadata such as response length, HTTP status code and MIME type.

    16. Display filter - The site map has a display filter that can be used to hide some of its content from view, to make it easier to analyze and work on the content you are interested in.
    Request type- You can show only in-scope items, only requested items, only requests with parameters, or you can hide not-found items.
    MIME type - You can configure whether to show or hide responses containing various different MIME types, such as HTML, CSS, or images.
    Status code- You can configure whether to show or hide responses with various HTTP status codes.
    Folders - You can optionally hide empty folders in the tree view. This is useful to remove folders whose child items have all been hidden by other display filter attributes.
    Search term- [Pro version] You can filter on whether or not responses contain a specified search term. You can configure whether the search term is a literal string or a regular expression, and whether it is case sensitive. If you select the "Negative search" option, then only items not matching the search term will be shown.
    File extension- You can configure whether to show or hide items with specified file extensions.
    Annotation - You can configure whether to show only items with user-supplied comments or highlights.
     Note: - If you set a filter to hide some items, these are not deleted, only hidden, and will reappear if you unset the relevant filter.
      (Click image for large view)
    Like it ? Share it.