Posts Tagged ‘web-application’

This weeks question of the week was asked by user Yoav Aner, who wanted to understand the legal and ethical concerns of executing an attack on a web site which carried a notice inviting attacks. Yoav specifically wanted to know what, if any contractual implications there were and if it were not specified, how far would be too far. This spun off into two further questions – What security measures to have before openly allowing security researchers to hack your site and What security concerns should one bear in mind when hacking open-invitation websites? so this post will look at all three.

Before we start, I must re-iterate: we are security professionals here, not lawyers, so if in doubt, consult a lawyer.

Legal and ethical concerns:

The answer Yoav accepted was provided by Rory McCune, who raised the point that ultimately, a no holds barred approach is extremely unlikely to be acceptable in any circumstance. Rory highlighted the importance of ensuring the page in question was written by the administrators of the site, as opposed to being supplied through user content. Clearly, unless it is clear the page was written by someone with the authority to make that kind of invitation, attacking it would definitely be hostile.

Another excellent point raised in this answer was that some companies actively invite finding bugs in their web sites and products, provided you follow a number of guidelines. More on this can be found in the answer itself.

Finally, Rory touched on what many people may forget – although the website may invite attempted break-ins, it may actually be illegal where you are even to make the attempt.

Our next answer was provided by Security moderator, user and blogger Rory Alsop. According to Rory, one problem when dealing with this kind of issue is that no test cases have yet passed through the courts – so until they do, it’s unlikely any precedent has been established for dealing with these kinds of issues. Rory also raised the criminal activity point again. Always understand that the law of your country/jurisdiction still applies.

Next up, Rory explained that during a penetration test a contract established for the work may include rules about what should happen, how far a test may go, who should be notified if a vulnerability is found etc. Even with this safeguard, there is still the potential for legal action should something break. Rory advised logging absolutely everything that was going on so as to have proof of actions.

When applied to the website scenario, Rory pointed out that in this case there is no signed contract establishing this understanding, just an implication of one which neither party is legally bound to.

That is all for answers on this question. I tend to miss questions on ethics on the main site, so writing them up is actually quite interesting. As such, I am going to summarise the key points below:

1. The rules of engagement are not well established. Assuming a “feel free to hack this message” we have no idea to what extent that is actually what they mean. By contrast, penetration testing is usually better scoped.
2. The author of the page might not have the authority to make such an invitation. As I was reading this, I did wonder – if this is a shared host, the administrator of the site is a different person from the company who owns and maintains the box. So even though the site author can put up this message, they’re not actually entitled to make that call (and it probably violates the ToS on their hosting package).
3. It may be illegal to engage in the act of attempting, whether or not the site in question has given you permission.
4. Some sites actively encourage hunting for bugs.

Security concerns when hacking open-invitation websites:

Iszi raised the following worries on his question

• The site could be a honeypot, run by government or other entities looking to gather information about active (or would-be) hackers.
• The site could be set up by a black-hat as a honeypot to gather a list of interesting, hackable amateurs to target.
• A third-party black-hat could potentially access the site’s logs and farm them for data about interesting, hackable amateurs to target.

Lucas Kauffman confirmed that he had a school project where he faked an open sendmail relay and

just piped all the incoming emails to a python script that got all the destinations out, generating my own spamlist. I think in the end after about 3 weeks I had close to 300.000 different email addresses.

Rory Alsop focused on the reputational and professional risks, as the host of the site will be able to see everything you did in their logs…do you ever mistype commands, use dir instead of ls, accidentally stray outside the scope of the test? This will be recorded and could negatively impact you.

Think about what you are divulging when hacking a website….

• Your methodology
• Your tools
• Your mistakes?
• etc

Finally – Yoav also asked a question focusing on the other side,

What security measures should I have in place before inviting people to hack my website?

Ttfd’s answer went into some considerable detail on the practical logistics – how you think about the problem is probably as important as actually implementing security in this situation:

1. Do you have the money to do that?
2. Do you have the resources? (servers, security teams and etc)
3. How far can you limit the damages a hacker can make to your system? I.E. If a hacker hacks into your server what access will he have ? Will he be able to connect to your database and retrieve/store/update data? Is your data encrypted ? Will he be able to decrypt it? (and so on)
4. Can your security team find how a hacker exploited your system?
5. Does your security team have the skills to fix problems that may occur ?
6. Probably many more questions that you need to ask and answer before you decide.

M15K gave a summarised answer

I can’t imagine very many positive scenarios in declaring open season on you’re front door will result in something useful. But let’s say you do, and you do get some positive feedback. Are you and your security team in a position to remediate those vulnerabilities?

Interesting stuff! All in all, this looks like a relatively risky business on both sides, so core to the decision must be a full understanding of the risks, and how these match to your risk appetite. If you are hosting such a site, you may get some valuable information into attack techniques, but you need to protect yourself from an escalation from the attack environment to your own systems. If you are testing the site, think about the risks you may be facing, and plan accordingly.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com. 

Our question of the week this week was asked by Iszi, who wanted to know how exactly we should determine what to trust when employing NoScript. In the question itself Iszi raises some valid points: how does somebody know, other than by trial and error, whether scripts from a given site or third party site are trustworthy? How does a user determine which parts of the javascript are responsible for which bits of functionality? How do we do this without exposing ourselves to the risks of such scripts.

Richard Gadsden suggests one way to approach a solution is for each site to declare what Javascript it directly controls. He notes that such a mechanism could trivially be subverted if the responding page lists any and all javascript as “owned” by the site in question.

Such resource-based mechanisms have been tried and implemented before, albeit for a different problem domain (preventing XSS attacks). Cross-Origin Resource Sharing (W3C, Wikipedia) attempts to do just that by vetting incoming third party requests. However, like HTML-based lists, it does not work well when the trusted end users are “everyone”, i.e. a public web service.

Zuly Gonzalez discusses a potential solution her startup has been working on – running scripts on a disposable vm. Zuly makes some good points – even with a whitelisted domain, you cannot necessarily trust each and every script that is added to the domain; moreover, after you have made your trust decision, a simple whitelist is not enough without re-vetting the script.

Zuly’s company – if you’re interested, check out her answer – runs scripts on a disposable virtual machine rather than on your computer. Disclaimer: we haven’t tested it, but the premise sounds good.

Clearly, however, such a solution is not available to everyone. Karrax suggested that the best option might be to install plugins such as McAfee SiteAdvisor to help inform users as to what domains they should be trusting. He notes that the NoScript team are beginning to integrate such functionality into the user interface of NoScript itself. This is a feature I did not know I had, so I tried it. According to the trial page, at the time of writing the service is experimental, but all of the linked to sites provide a lot of information about the domain name and whether to trust it.

This is an area with no single solution yet, and these various solutions are in continuous development. Let’s see what the future holds.

This week’s post came from this question: I just discovered major security flaws in my web store!, but covers a wider scope and includes some resources on Security Stack Exchange on defending your website.

Any application you connect to the Internet will be attacked within minutes of plugging it in, so you need to look very carefully at protecting it appropriately. Guess what – many application owners and developers go about this in entirely the wrong way, building the application and then thinking about security at the very end, where it is expensive and difficult to do well.

The recommended approach is to build security in from the start – have a look at this post for a discussion on Secure Development Lifecycle. This means having security as a core pre-requisite, just like performance and functionality, and understanding the risks your new application will bring. Read How do you compare risks from your websites, physical perimeter, staff etc

To do this you will need developers to write the application securely. Studies show that this is the most cost effective in the long run, as securely developed applications require very little remediation work (as they don’t suffer from anywhere near as many security flaws as traditionally developed applications)

So, educating developers is key – even basic awareness can make the difference: What security resources should a white-hat developer follow these days?

Assuming your application has been developed using secure practices and you are ready to go live, What are the most important security checks for new web applications? and Testing your web application to gain some confidence that the security controls you have implemented are correctly working and effective is an essential step before allowing connection to the Internet. Penetration testing and associated security assessments are essential checks.

What tools are available to assess the security of a web application?

The globally recognised open standard on web application security is the Open Web Application Security Project, (OWASP) who provide guidance on testing, sample vulnerable applications, and a list of the top ten vulnerabilities. The answers to Is there a typical step-by-step A-Z process for testing a Web site for possible exploits? provide more information on approaches, as do the answers to Books about Penetration Testing.

Once your application is live, you can’t just sit back and relax, as new attacks are developed all the time – being aware of what is being attempted is important.  Can I detect web app attacks by viewing my Apache log file is Apache specific, but the answers are broadly relevant for all web servers.

This is obviously a very quick run-through – but reading the linked questions, and following the related questions links on them will give you a lot of background on this topic.