Burpsuite Browser Not Opening
Agalia Valcin
Burp is designed to be used alongside your browser. Burp functions as an HTTP proxy server, and all HTTP/S traffic from your browser passes through Burp. To do any kind of testing with Burp, you need to configure your browser to work with it.
Firstly, you need to confirm that Burp's Proxy listener is active and working. Go to the Proxy tab, then the Options sub-tab, and look in the Proxy Listeners section. You should see an entry in the table with the checkbox ticked in the Running column, and "127.0.0.1:8080" showing in the Interface column. If this is not the case, try pressing the "Restore defaults" button to the left of the panel. If the listener is still not running, then Burp was not able to open the default Proxy listener port (8080). You will need to select the table entry, click "Edit", and change the port number of the listener to a different number. See the Proxy listeners help for more details.
Secondly, you need to configure your browser to use the Burp Proxy listener as its HTTP proxy server. To do this, you need to change your browser's proxy settings to use the proxy host address (by default, 127.0.0.1) and port (by default, 8080) for both HTTP and HTTPS protocols, with no exceptions. The details of how to do this vary by browser and version, but are roughly as follows:
When you've configured your browser, you need to test that it is working properly. With Burp running, in your browser go to any HTTP URL (don't use HTTPS for the moment). Your browser should sit waiting for the request to complete. In Burp, go to the Proxy tab, and then the Intercept sub-tab. These tabs should be highlighted, and there should be an HTTP request showing in the main panel. Click on the "Intercept is on" button so that it says "Intercept is off". Go back to your browser, and you should (shortly) see the URL you requested being loaded in the normal way. If things aren't working in the way described, please refer to the troubleshooting help.
Finally, you need to configure your browser to be able to send HTTPS requests through Burp without any problems. This step isn't strictly necessary to use Burp in a basic way or only for non-HTTPS URLs, but it only needs to be done once and is necessary to get the most out of Burp when testing applications that use HTTPS. The reason for this requirement is that Burp breaks SSL connections between your browser and destination web servers, in order to view and modify the plain contents of HTTPS messages. SSL is designed to prevent this happening, and so by default your browser will show a security warning when you visit an HTTPS URL using Burp. To ensure that applications using HTTPS function properly, you need to install Burp's Certificate Authority (CA) SSL certificate in your browser trust store. For detailed help on doing this, please refer to the help on installing Burp's CA certificate. When you have done this, you can confirm things are working properly by closing all your browser windows, opening a new browser and visiting any HTTPS URL. The browser should not display any security warnings, and the page should load in the normal way (you will need to turn off interception again in the Proxy Intercept tab if you have re-enabled this).
I have a requirement of hashing/encrypting the password at client side, as the password can be seen in plain text in the browser using developer mode or using tools like burp suite. Based on my research so far it can be done by calling the java script at Login page to encrypt the password and then decrypt it before calling User_Login method which is called on Login button.
The password can only be seen in clear text in the same browser the user typed it in. So we're talking about a user typing in a password, then the same user opening developer tools and reading the password? I don't think it's a security risk to let the user read its own password.
And, if you want to make sure the password cannot be read even by using developer tools, then I'm going to say that someone with access to developer tools could simply hijack your javascript encryption function and store the clear text password before encrypting it. Developer tools has all the privileges to change javascript code.
The only advantage I see in that extra encryption layer is to protect against super-powerful organisations, such as governments that could compromise root CA certificates, or develop some attack on the SSL protocols. That has happened in the past, with NSA eavesdropping on SSL traffic. Is that your scenario?
Never ever try to "add a security layer" when you have clearly no clue as to what "security" actually is. Leave that to the experts :). As Leonardo already wrote, trying to do what you do does not give any extra security, and symetric encryption isn't very secure to begin with.
While this information might already be available in various online forums or quickly retrieved via searching online, there are certain situations where manual intervention might be needed to update the Burp Suite installation in Kali Linux. Upon opening the Burp Suite application in Kali, there is a persistent alert notification that prompts downloading a new version of Burp Suite. Even after running several software updates, followed by package updates through the 'apt-get update' command on Kali, it was still necessary to manually update Burp Suite so that the update could work. Burp Suite can be quickly launched via Applications > Web Applications under numerous sub-menus. It can also be launched from Top 10 Security Tools. Usually, Burp Suite resides in /usr/bin.
To check if an automatic update is possible, click on the update prompt if it appears. One can also check the Burp Suite update by clicking on Help > Check for Updates, as shown below. If any updates are shown to be available, one can follow the prompts in the subsequent popup window to complete the download.
In case the above methods fail, one should consider manually downloading the JAR file from the Burp Suite website and try to place it in the /usr/bin directory or in Burp Suite's Installation directory in the Kali installation. To update Burp Suite in this manner, download a copy of the latest version of Burp Suite from the official Portswigger website:
Navigating to the Burp Suite Releases page in a browser, selecting JAR from the second drop-down menu, then clicking on Download, or visiting this direct download link to get the JAR file if the latest release version number is known -
The required Burp Suite version can be in a variable, or one should be able to change this to the latest version (in the version parameter of the URL below) by visiting the Burp Download page and checking out the version of the latest release. Then, the manual JAR download can be done by the following command, and the required version can be added to it -- wget " =community&version=2020.12.1&type=Jar".
Upon launching Burp Suite again, one will notice that they won't be alerted that a new update is available for Burp Suite, proving that the latest version of Burp Suite is now running on the machine. After a successful launch, the old Burp Suite installation file can be safely removed (or deleted) from the */usr/bin *directory, which was already accomplished by renaming and moving the newly downloaded JAR file the directory of the original burp installation. Note: One can write a shell script to automate the process for subsequent manual updates, making this process even easier, in case it's needed.