|
Okay, this is not really security related but I figured I would post it anyways.
[ 1 comment ] ( 13 views ) [ 0 trackbacks ] permalink http://www.improveverywhere.com/2008/01 ... d-central/    ( 2.9 / 102 )
Yesterday, I was discussing with Jcran the risk associated with Cross Site Scripting and Redirects. First let me say, I know that URL redirects are an example of XSS. The type of Cross-Site Scripting vulnerability we were discussing is the reflective XSS. To clarify, URL redirects I mean taking a parameter which could be modified by the client, usually in a GET parameter being passed to a page which redirects to the parameter passed in.
[ 2 comments ] ( 30 views ) [ 0 trackbacks ] permalink Both of these vulnerabilities provide similar types of attack vectors against the client. Jcran took the view that reflective XSS has a greater risk associated with it since it does not require the client to navigate to another page the client may not trust. This is a fair assumption, however having software that does this sort of restriction is not very common in my opinion. If the client is restricting the browser to only pages that they "trust" then reflective XSS in this case is ideal. However, it is not always the case that the client is performing such restrictions on the browser. If the page is performing some validation which restricts the type of input that can be done, this will limit the attack vectors. For example, if the page does not allow various Javascript related functions. These types of restriction can be bypassed in certain cases but this is not possible or practical due to time frame limitations. If the attackers were to use a redirect then they would have no limitations on the type of attack that could be performed against the client. They would only need to bypass the software limiting the pages the client can navigate to. If the attacker uses this then they are not restricted in the type of attacks they can perform against the client. It is interesting that there have not been a larger number of redirect vulnerabilities being disclosed in the security community. This may be due to the fact that some consider XSS to be a "lame" attack which should not be discussed on FD etc etc. I dunno just a few thoughts I have had. ( 1.7 / 303 )
So this November Nikto 2.0 was released. Having used Nikto 1.0 in the past, I decided to give version 2.0 a try and I was very impressed. I was so impressed that I decided that I would contribute to the project.
[ add comment ] ( 10 views ) [ 0 trackbacks ] permalink In mid December, I had sometime to take another look at Nikto 2.0 and dive into some code. One thing that I thought was missing was the lack of XML support. Therefore, I wrote an email to Sullo (Nikto's author) and asked him if he had any plans to add XML support. He told me that if I wanted to add XML support he would apply the patch(es) to Nikto. One of the main changes for 2.0 was adding HTML template files which separated the HTML formating from the data. I decided that this would be ideal for adding XML, because I would only need to pass the data to the template. So I did some research on building a DTD and built a DTD that I would base the XML on. Once I completed the DTD, I used the HTML templates as a base for building the XML templates. I configured the XML templates to meet the DTD specification. I added the XML format to the nikto_core.plugin so that it would execute the appropriate subroutines. Next, I added a few subroutine to write the XML in nikto_reports.plugin. I spoke with Jon and he suggested that each item that Nikto finds should have a unique ID. The reason for this is that it would be easy to determine the changes between two scans if everything had a unique ID (think PBNJ heh). I suggested this to Sullo and he added the IDs for everything in Nikto. Then I updated the DTD and XML templates to include the IDs. Finally, the patches were done and with that, Nikto 2.02 was released. I am very happy that I could contribute to Nikto. I look forward to using Nikto and the new XML output in the future. ( 3 / 123 )
So many people use either Google or tools like goog-mail.py to generate email lists when performing a penetration test. However, goog-mail to be frank, sucks. So I have thought about a smarter way to gather email lists. It occurred to me that if you knew the scheme which a company uses to generate the email addresses, you could simply generate email addresses using a list of names.
[ 1 comment ] ( 16 views ) [ 0 trackbacks ] permalink Therefore, instead of scraping Google all day, we only need to find a list of names and generate the email address lists ourselves. Sometimes, we don't know the scheme and therefore, we can attempt a bunch and determine the scheme based on error responses from sending an email. Here are a few examples The code can be found at http://spl0it.org/files/genemailaddrs.pl Enjoy! ( 3.1 / 112 )
So I have written a normal DNS BruteForcing tool a few times before. However, I have yet to write an extension Brute Force tool so I wrote one.
[ 2 comments ] ( 66 views ) [ 0 trackbacks ] permalink http://spl0it.org/files/ext_brutedns.pl $ perl ext_brutedns.pl -d google.com I have also added a module to do this to the next version of Fierce! ( 3 / 133 )
|
Most Recent Entries
