'SECURITY'에 해당되는 글 5건

2012.12.05 6.Cross-Site Request Forgery (CSRF)
2012.11.13 3. Session fixation vulnerability
2012.11.13 2. XSS(cross-site scripting) attacks
2012.11.12 1. SQL Injection
2012.11.12 OWASP_T10

6.Cross-Site Request Forgery (CSRF)

SECURITY 2012. 12. 5. 14:06

아래 프로젝트 파일 실행 후 다음과 같은 과정을 걸쳐 CSRF를 이해함

프로그램 설명 : Login 한 사용자가 다른 사용자에게 송금을 한다.

CsrfDemo.zip

CSRF 실습과정

1. 사용자가 로그인한다.

2. 100원을 bad guy에게 송금한다.

3. Post로 요청하였지만 fidder에서 보면 Rest Service 의 주소와 내용을 알 수 있다.

4. 3번 내용을 가지고 웹페이를 만들어 실행한다. (

- 저자가 제공한 사이트 사용 : http://demo.haacked.com/security/csrf-mvc.html)

- 같은 세션을 가지고 있어야 하므로 탭으로 열고 붙여넣기 후 클릭

- 실제 해킹할 때는 Cross-domain 정책이 적용되어 있을 것이므로 해당 사이트에 아래 html 파일을 업로드 후 실행하지 않을까하는..

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title></title>
</head>
<body>
    <form name="badform" method="post" action="http://localhost:54607/Home/Transfer">
        <input type="hidden" name="destinationAccountId" value="2" />
        <input type="hidden" name="amount" value="1000" />
    </form>
    <script type="text/javascript">
        document.badform.submit();
    </script>
</body>
</html>

5. 다른 사이트에서 bad guy에게 돈이 송금된 것을 확인(\1000원을 송금 : \400 => - \600 )

6. 정상적으로 service를 call 했을 때와 다른 사이트에서 call 했을 때 referer가 다른 것을 알 수 있다.

참고 사이트 : http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx

CSRF를 막는 방법 참고 사이트 : http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

3. Session fixation vulnerability

SECURITY 2012. 11. 13. 10:58

ASP.NET Session hijacking with Forms authentication 동영상
: http://www.youtube.com/watch?v=DcmUo5FMLyI

Introduction

ASP.NET Session keeps track of the user by creating a cookie called “ASP.NET_SessionId” in the user browser. This cookie value is checked for every request to ensure that the data being served is specific to that user. In many application, Session variable is used to track the logged in user, ie. If a session variable exists for that user then the User is logged in otherwise not.

SessionAttackSample.zip

ASPX PAGE

<fieldset>
<legend>Login</legend>
<p>
Username :<asp:TextBox ID="txtU" runat="server" />
</p>
<p>
Password :<asp:TextBox ID="txtP" runat="server" />
</p>
<p>
<asp:Button ID="btnSubmit" runat="server" Text="Login" OnClick="LoginMe" />
<asp:Label ID="lblMessage" runat="server" EnableViewState="false" />
<asp:Button ID="btnLogout" runat="server" Text="Logout" OnClick="LogoutMe" Visible="false" />
</p>
</fieldset>

In the above code snippet, we have two TextBoxes, two Buttons and a Label control.

CODE BEHIND

protected void Page_Load(object sender, EventArgs e)
{
if (Session["LoggedIn"] != null)
{
lblMessage.Text = "Congratulations !, you are logged in.";
lblMessage.ForeColor = System.Drawing.Color.Green;
btnLogout.Visible = true;
}
else
{lblMessage.Text = "You are not logged in.";
lblMessage.ForeColor = System.Drawing.Color.Red;
}
}
protected void LoginMe(object sender, EventArgs e)
{
// Check for Username and password (hard coded for this demo)
if (txtU.Text.Trim().Equals("u") && txtP.Text.Trim().Equals("p"))
{
Session["LoggedIn"] = txtU.Text.Trim();
}
else
{lblMessage.Text = "Wrong username or password";
}
}
protected void LogoutMe(object sender, EventArgs e)
{
Session.Clear();
Session.Abandon();
Session.RemoveAll();
}

On click of the Login button, LoginMe method fires that creates Session[“LoggedIn”] after validating the TextBoxes value.

On click of the Logout button, we are calling Session.Clear(), Session.Abandon() and Session.RemoveAll() methods to ensure that the session variable is removed.

Output

ASP.NET_SessionId cookie when user is logged in

Notice in the below image that when user has logged in, an “ASP.NET_SessionId” cookie has been created.

(After clicking on Login, go back and refresh the page)

Now when we clicked on Logout button, even if the Session has been abandoned / removed, the “ASP.NET_SessionId” cookie exists.

ASP.NET_SessionId cookie even if user is logged out

(After clicking on Login, go back and refresh the page)

How to fix this vulnerability

Simple fix

To avoid Session fixation vulnerability attack, we can explicitly remove the “ASP.NET_SessionId” cookie in the Logout method.

Bullet proof fix

To bullet proof this attack, we can create another cookie (eg. AuthCookie) with a unique value and the same value can be stored into the Session as well. On every page load, we can match this cookie value with the Session value, if both matches then let the use enter into the application otherwise redirect to the Login page.

In the Logout function, ensure that you are removing this new Cookie “AuthCookie” as well. To remove this cookie, simply set its expiration date time to few months earlier than current date time.

So my modified code behind for this page looks like below

MODIFIED CODE BEHIND

protected void Page_Load(object sender, EventArgs e)
{
//NOTE: Keep this Session and Auth Cookie check condition in your Master Page Page_Load event
if (Session["LoggedIn"] != null && Session["AuthToken"] != null && Request.Cookies["AuthToken"] != null)
{
if (!Session["AuthToken"].ToString().Equals(Request.Cookies["AuthToken"].Value))
{
// redirect to the login page in real application
lblMessage.Text = "You are not logged in.";
}
else
{lblMessage.Text = "Congratulations !, you are logged in.";
lblMessage.ForeColor = System.Drawing.Color.Green;
btnLogout.Visible = true;
}
}
else
{lblMessage.Text = "You are not logged in.";
lblMessage.ForeColor = System.Drawing.Color.Red;
}
}
protected void LoginMe(object sender, EventArgs e)
{
// Check for Username and password (hard coded for this demo)
if (txtU.Text.Trim().Equals("u") && txtP.Text.Trim().Equals("p"))
{
Session["LoggedIn"] = txtU.Text.Trim();
// createa a new GUID and save into the session
string guid = Guid.NewGuid().ToString();
Session["AuthToken"] = guid;
// now create a new cookie with this guid value
Response.Cookies.Add(new HttpCookie("AuthToken", guid));
}
else
{lblMessage.Text = "Wrong username or password";
}
}
protected void LogoutMe(object sender, EventArgs e)
{
Session.Clear();
Session.Abandon();
Session.RemoveAll();
if (Request.Cookies["ASP.NET_SessionId"] != null)
{
Response.Cookies["ASP.NET_SessionId"].Value = string.Empty;
Response.Cookies["ASP.NET_SessionId"].Expires = DateTime.Now.AddMonths(-20);
}
if (Request.Cookies["AuthToken"] != null)
{
Response.Cookies["AuthToken"].Value = string.Empty;
Response.Cookies["AuthToken"].Expires = DateTime.Now.AddMonths(-20);
}
}

LoginMe method

First focus on the LoginMe method that fire on click of the Login button. In this method, after setting the normal Session variable, we are creating a GUID (a unique value and almost impossible to guess) and saving it as a new Session variable called “AuthToken”. The same GUID is being saved into a cookie named “AuthToken”.

LogoutMe method

In the LogoutMe method, we are first explicitly expiring the “ASP.NET_SessionId” cookie to make sure that this cookie is removed from the browser when user clicks on the Logout button and after that we are expiring the “AuthToken” cookie as well.

Page_Load event (In real time application, keep this logic into the Master Page Page_Load method)

In the Page_Load event we are checking for the normal “LoggedIn” session variable and along with that we are also checking for the new Session variable called “AuthToken” and new Cookie “AuthToken”, if all three of them are not null then again we are matching the new Session variable “AuthToken” and new Cookie “AuthToken” values, if both are NOT same, then we are writing failure message (in real time application, redirect the user to the Login page).

This logic makes sure that even if “ASP.NET_SessionId” cookie value is known to the hijacker, he will not be able to login to the application as we are checking for the new Session value with new cookie that is created by us and their GUID value is created by us. A hijacker can know the Cookie value but he can’t know the Session value that is stored into the web server level and as this AuthToken value is changing every time user is logging in so the older value will not work and hijacker will not be able to even guess this value. Unless the new Session (“AuthToken”) value and new Cookie (“AuthToken”) is same, no one will be able to login to the application.

OUTPUT

ASP.NET_SessionId along with AuthToken cookie

복사한 사이트 : http://www.codeproject.com/Articles/210993/Session-Fixation-vulnerability-in-ASP-NET

참고 : HTTP Session Hijacking

HTTP 프로토콜의 특성

HTTP는 기본적으로 비연결유지(stateless) 프로토콜이다. 반면, telnet과 ftp와 같은 프로토콜은 클라이언트와 서버 사이에 하나의 연결(session)이 성립되어 통신하는 프로토콜이다. 따라서, 우리가 보통 웹 브라우저를 열어 URL을 입력하고 해당 홈페이지에 들어간다는 것은 해당 홈페이지에 포함되어 있는 페이지(html), 그림(jpg, gif 등), 자바스크립트(js) 등을 다운받기 위해 개별적인 여러 개의 80 요청(request)을 발송한 후 서버로부터 각각의 응답(reply)을 받는 것을 의미한다.

이러한 일련의 요청과 응답이 이루어진 후 해당 서버와의 통신은 다시 종료된다. 위와 같은 기본적인 지식을 알고 있다면 다음과 같은 질문을 할 수 있다. HTTP는 비연결유지 프로토콜이라고 하였는데 Session Hijacking 이란 공격은 어떻게 가능한 것인가? 이는 HTTP 세션 관리를 위해 사용되는 Session ID를 통해서 가능하다.

Session ID란 무엇인가?

웹 서버는 다수의 웹 페이지 요청자를 구별하기 위하여 각각의 사용자의 세션에 대해서 임의의 긴 문자열 값인 Session ID를 부여한다. 사용자가 홈페이지 방문시 혹은 인증 로그인시에 생성된다. 이러한 Session ID는 사용자의 계정, 암호, 그 밖의 IP 주소, timestamp 등의 여러 파라미터들을 조합하여 생성할 수 있다.

Session ID는 사용자와 일련의 웹 서핑 동작을 연결시켜줌으로써 웹 사이트 로그인 후 다른 페이지 방문시마다 매번 로그인을 하지 않아도 되는 편리함을 제공해준다.

우리가 신문 홈페이지나 포털 사이트에 들어갈 때 광고 배너가 자동으로 바뀐다던지, 쇼핑몰이나 인터넷 서적몰에서 구매 카트의 목록이 유지되는 것은 모두 이러한 원리이다. 즉, Session ID를 통해 인증과 인가(authentication
& authorization)라는 세션 관리를 수행할 수 있다.

Session ID는 어디에 존재하는가?

Session ID는 우리가 흔히 듣는 쿠키(cookie)라는 곳에 저장되는 것이 일반적이다. 그러나 가끔은 웹 브라우저 주소창 URL이나 HTML 페이지 폼 소스 상의 hidden 필드에 포함되어 드러나기도 한다.

1) 쿠키

2) 웹 브라우저 주소창의 URL

3) 웹 페이지 폼 소스 상의 hidden field

Session ID의 취약성은 무엇인가?

웹 서버에서의 Session ID 생성 기법 및 관리 기법에 따라서 다음과 같은 취약점이 존재할 수 있다.

강력하지 못한 알고리즘(Weak Algorithm) : session ID 스트링 값을 생성함에 있어서 공격자가 reverse 엔지니어링이 가능한 쉬운 알고리즘으로 생성될 경우 cracking이나 brute-force guessing 공격의 위험이 있다.

길이가 짧은 Session ID : 강력한 암호 알고리즘을 사용하더라도 그 길이가 충분하지 않고 짧은 경우에는 cracking이나 brute-force guessing 공격의 위험이 있다.

계정 잠금 기능 미비 : 로그인 패스워드의 특정 회수 실패에 대해서는 보통 계정잠금 기능이나 해당 IP 차단 기능을 구현하고 있습니다. 그러나 보통 Session ID에 대한 무결성 침해나 특성 회수 실패에 대해서는 이러한 잠금 기능 구현이 미비하다. 따라서, brute-force guessing 공격의 위험이 있다.

무한 만료의 Session ID : 사용자의 로그 아웃 이후에도 서버측에서 해당 세션 ID값을 폐기하지 않고 무한정 유효 인정한다면 cookie sniffing이나 프락시 서버의 로그 취득을 통하여 session ID 공격이 가능하다.

평문으로 전달되는 Session ID : 서버에서 클라이언트로의 session ID 쿠키 전달 방식이 비암호화 방식일 경우에는 sniffing을 통하여 해당 값이 노출되어 공격 받을 수 있다. 특히 Session ID 값 자체가 사용자명이나 암호 등의 평문으로 구성되어 있는 경우에는 직접적인 공격이 가능하다.

위와 같은 취약성에 대한 Session ID 공격의 유형은 다음과 같다.

Session ID 공격유형

직접적인 Cookie Sniffing을 통한 Session ID 도용

간접 우회 공격을 통한 Session ID 도용

Brute-force guessing을 통한 Session ID 도용

지금까지 Session ID가 무엇인지, 어떤 형태로 존재하는지, 왜 취약한지에 대해서 알아보았다. 다음에는 실제 공격 유형에 대해 살펴보고, 대응 방안에 대해서도 논의해 보도록 하겠다.

Session ID 공격 유형

Session ID에 대한 공격은 크게 2 단계로 이루어진다. 1단계는 Session ID 취득 단계이고 2단계는 취득한 Session ID 공략 단계이다.

[그림1] HTTP Session Hijacking 공격 흐름도

공격자는 Session ID를 취득하기 위하여 웹 서버와 웹 클라이언트의 트래픽을 직접적으로 스니핑하거나, 웹 서버 상에 공격 코드를 삽입하여 두고 사용자가 클릭할 때 Cookie, Session ID 값을 전송받을 수 있도록 한다. 웹 서버와 웹 클라이언트 사이의 트래픽을 직접적으로 스니핑하는 방법은 일반적인 네트워크 트래픽 스니핑 기법을 통해 가능하다.

POST /xxxxxx HTTP/1.1Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*Referer: http://xxx.xxx..comAccept-Language: koContent-Type: application/x-www-form-urlencodedAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)Host: ibn.kbstar.comContent-Length: 297Connection: Keep-AliveCache-Control: no-cacheCookie: Session=QJ48621878865

[그림2] 네트워크 트래픽 스니핑을 통한 HTTP 요청 헤더 안의 쿠키값

웹 서버 상의 HTML 코드 삽입이 가능한 페이지는 주로 사용자가 글을 게시할 수 있는 게시판이나 자료실 등에 존재한다. 정상적인 글을 게재하는 대신 공격자는 HTML 코드 및 스크립트를 심어 넣는다. 일반 사용자는 해당 게시물을 열람하게 될 때 자신도 모르는 사이 Cookie, Session ID 정보가 제 3 의 공격자 서버나 이메일로 전송되게 된다. (이러한 공격 기법을 Cross-Site Scripting이라고 부른다.)

<form name=f method=POST action="http//host/hello.php"><input type=hidden name="name"value="<script>alert(document.cookie)</script>"></form><script>f.submit()</script>

[그림3] 쿠키값 탈취를 위한 HTML 삽입 코드 예

결과적으로 공격자는 취득한 타인의 Session ID 값을 웹 서버에 요청함으로써 HTTP Session Hijacking 공격을 시도할 수 있다. 물론 이 공격이 성공하려면 Session ID 값이 유효해야 하므로, 사용자가 로그온 한 상태에서 공격이 이루어져야 하거나 Session ID 값의 유지 시간이 긴 경우라는 제한 사항이 필요하다.

그러나, 기본적으로 잘못 설계된 세션 관리 기법을 사용하고 있는 웹 서버는 이러한 Hijacking 공격에 취약할 수 밖에 없다. 굳이 타인의 Session ID 값을 직.간접적으로 취득하지 않고도 무작위 추측 대입(Brute-force Guessing)함으로써 공격이 가능하다. 공격자는 정상적인 로그인 과정시 분석한 자신의 Cookie 값, 웹 브라우저의 주소창의 URL, 웹 페이지 폼 소스 hidden field 내에 노출된 Session ID 값 자체를 분석한다.

Session ID 생성 방식의 취약점을 파악한 후, 공격자의 컴퓨터에서 로컬 프록시 툴이나 웹 브라우저 창 URL 주소창에서 직접 Sessioion ID 값 단일 대입을 시도한다. 더 나아가 자동적인 Session ID 대입 스크립트를 작성하여 공격할 수도 있다.

http://mmail.xxx.co.kr/mletter1/read_mail.asp?id=2266&tableName=musicMail1927&fromEmail=xxx@xxx.co.kr
http://www.xxx.co.kr/view/UID2305670410000
http://www.xxx.co.kr/view/UID2305670410341
http://www.xxx.co.kr/view/UID2305670411302

[그림4] 정상적인 Session ID 값

http://mmail.xxx.co.kr/mletter1/read_mail.asp?id=3734&tableName=musicMail1927&fromEmail=xxx@xxx.co.kr
http://www.xxx.co.kr/view/UID2305670410001
http://www.xxx.co.kr/view/UID2305670410002
http://www.xxx.co.kr/view/UID2305670419999

[그림5] 무작위 추측 대입된 Session ID 값

대응 방안

HTTP Session Hijacking 공격에 대하여 웹 어플리케이션 개발자는 다음과 같은 점을 고려하여 세션 관리 기법을 구현하여야 한다.

1. Session ID 생성 범위값을 사용자 수에 대비하여 충분히 큰 값으로 설정한다.
2. Session ID는 가능한 한 추측 불가능(random)하게 생성한다. 무작위 추측 대입 공격을 할 때 공격자는 그만큼 더 많은 시간을 투입하여야 하며 현재 연결되어 활성화 되어 있는 유효한 Session ID 값을 찾는 확률은 낮아진다.
3. Session Timeout 기능과 Session ID 재생성 기능을 사용한다. 일정 시간 동안 활동이 없는 사용자는 새로운 Session ID로 재로그인하도록 하고, 사용자 로그 아웃 시에는 Session ID 값을 폐기한다. 장시간 접속이 필요한 어플리케이션의 경우에는 일정 주기마다 Session ID값을 자동으로 재생성하여 세션을 유지하도록 한다.
4. 무작위 추측 대입(Brute-force Guessing)에 대비하여 일정 회수 이상의 인증 실패시에는 사용자 잠금 기능을 구현한다.
5. 로그인 이후에도 중요한 서비스 이용시에는 사용자 인증을 통하여 인가된 사용자만이 해당 서비스를 이용할 수 있도록 통제한다.
6. Cookie 내용 안의 Session ID와 기타 변수값 자체를 암호화한다.
7. 웹 서비스 자체의 중요성에 따라 Cookie가 전달되는 방식을 SSL로 구현함으로써 스니핑 공격에 대응할 수도 있다.
8. 웹 서비스 상에 공격자가 HTML 공격 코드 삽입이 가능한 페이지가 있는지 점검한다. 직접적인 공격 코드 삽입을 차단할 수 있도록 특수 문자 및 스크립트 코드를 필터링하여야 한다.

지금까지 HTTP Session Hijacking 공격 기법에 대해서 알아보았다. 대부분이라고 말할 수는 없지만 요즘 인터넷에 서비스되고 있는 인기 있는 웹 컨텐츠 서버는 기본적으로 안전한 세션 관리 기법으로 구현되어 있다. 그러나, 웹 컨텐츠의 인지도와는 별도로 이러한 공격 기법에 대한 인지 없이 비보안적으로 구현된 e-메일 카드 서비스, 전자 앨범 서비스 사이트 등이 다수 존재하는 것 또한 현실이다.

HTTP Session Hijacking공격에 대한 대비는 안전한 웹 어플리케이션 구축을 위한 여러가지 항목 중에 필수적인 한 가지 사항이며, 기획 및 개발구현 단계에서 반드시 고려되어야 한다.

[출처] 코코넛 시큐레터 2004년 5월호

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

2. XSS(cross-site scripting) attacks

SECURITY 2012. 11. 13. 10:03

아래 예제 MVC Project를 보면서 쉽게 이해하자.

XssAttackSample.zip

1. We start by modifying the HomeController / Index method

namespace XssAttackSample.Controllers
{
    public class HomeController : Controller
    {
        public ActionResult Index(string UserName)
        {
            ViewBag.UserName = UserName;
            return View();
        }

        public ActionResult About()
        {
            return View();
        }
    }
}

2. Then we add this information to the home index view,

@{
    ViewBag.Title = "Home Page";
}
<h2 id="welcome-message">Welcome to our website</h2>

@if(!string.IsNullOrWhiteSpace(ViewBag.UserName)) {
<script type="text/javascript">
    $(function () {
        var message = 'Welcome, @ViewBag.UserName!';
        $("#welcome-message").html(message).hide().show('slow');
    });
</script>
}

3. We tested that with the following url: http://localhost:13810/?UserName=hello. It seems to be OK.

4. But if we tested that with the following http://localhost:13810/?UserName=<script>alert('pwnd')</script>

As you can see, it was detected by request validation:

But since this value is being rendered via Javascript, it's vulnerable to Javascript encoding, which won't be picked up by the ASP.NET encoder. Try this url: http://localhost:13810/?UserName=Jon\x3cscript\x3e%20alert(\x27pwnd\x27)%20\x3c/script\x3e

Remember that we're using an alert here for demonstration purposes, but a real XSS attack will do something more sinister, designed so end users will never notice.

Fixing the Javascript encoding XSS vulnerability

A. There are two ways to handle this. The simplest is to use the @Ajax.JavaScriptStringEncode helper function

@{
ViewBag.Title = "Home Page";
}
<h2 id="welcome-message">Welcome to our website</h2>

@if (!string.IsNullOrWhiteSpace(ViewBag.UserName))
{
<script type="text/javascript">
    $(function () {
        var message = 'Welcome, @Ajax.JavaScriptStringEncode(ViewBag.UserName)!';
        $("#welcome-message").html(message).hide().show('slow');
    });
</script>
}

B. If we've included the AntiXSS library in our project, we can bring in the namespace with a @using Microsoft.Security.Application statement and call into the AntiXSS library's JavaScriptStringEncode function, which follows a whitelist approach to screen out alternate encodings and character sets.

@using Microsoft.Security.Application

@{
    ViewBag.Title = "Home Page";
}
<h2 id="welcome-message">Welcome to our website</h2>

@if(!string.IsNullOrWhiteSpace(ViewBag.UserName)) {
<script type="text/javascript">
    $(function () {
        var message = 'Welcome, @Encoder.JavaScriptEncode(ViewBag.UserName, false)!';
        $("#welcome-message").html(message).hide().show('slow');
    });
</script>
}

5. With either of the above two checks in place, the Javascript XSS injection is caught:

참고 사이트 : http://weblogs.asp.net/jgalloway/archive/2011/04/28/preventing-javascript-encoding-xss-attacks-in-asp-net-mvc.aspx

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

1. SQL Injection

SECURITY 2012. 11. 12. 17:36

아래 쿼리와 Watch 창에서 Injection되는 SQL을 보면 쉽게 이해 할 수 있다.

1. UI에서 Strssearch arg을 받아서 Grid에 보여주는 함수

        private void Show_Data(String strssearch)
        {
            string connectionName = "MYSTRING";
 
            ConnectionStringSettings cs =
                  ConfigurationManager.ConnectionStrings[connectionName];
 
            if (cs == null)
                throw new ConfigurationErrorsException("Invalid connection name \"" + connectionName + "\"");
 
            factory = DbProviderFactories.GetFactory(cs.ProviderName);
             using (DbConnection conn = factory.CreateConnection())
            {
                if (conn == null)
                    throw new Exception("Could not obtain connection from factory");
 
                conn.ConnectionString = cs.ConnectionString;
                conn.Open();
 
                String query = ""; 
 
                query += " select *           ";
                query += " from ARDOCUMENT    ";
                if (!string.IsNullOrEmpty(strssearch))
                {
                    query += " where DOCUTYPE = '" + strssearch + "'";
                }
                query += " order by CUSTOMERNAME   ";
                
                DbCommand cmd = factory.CreateCommand();
                cmd.Connection = conn;
                
                cmd.CommandText = query;
                DbDataReader reader = null;
 
                try
                {
                    reader = cmd.ExecuteReader();
                    GridView1.DataSource = reader;
                    GridView1.DataBind();
 
                }
                catch (Exception ex)
                {
                    string ExMsg = ex.Message;
 
                }
                finally
                {
                    reader.Close();
                }
            }
            
        }
 
 
2. UI에서 TXT를 입력을 하면  여러 row의 값을 가져와 보여준다.
 
 
아래 사진과 같이 SQL문이 만들어 진다.
 
 
 
 
 
 
 
 
 
3. 만약 'TXT' OR '1' = '1를 입력하게 된다면 어떤 일이 일어날까?
 
 
 
 OR '1' = '1 의 Sql 문이 injection 이 된 것을 확인 할 수 있다. 
 결과는 TXT 이 외의 table의 모든 값을 가져오게 된다.
 
 
 
 
 
site : Injection Attacks by Example 
 http://www.unixwiz.net/techtips/sql-injection.html
 
injetion을 막는 방법을 소개하는 site
http://www.mikesdotnetting.com/Article/113/Preventing-SQL-Injection-in-ASP.NET