언제나 공사중! :: SQL Injection을 막는 방법 #1

SQL Injection을 막는 방법 #1

일 2006/05/22 10:56

SQL Injection은 웹의 취약점으로 생긴다고 알고 있다. 이 SQL Injection은 그렇다. 분명한 취약점이다. 이 취약점이 문제가 되는 것은 정보가 빼돌려졌기에 대단히 위험도가 높은 것이다. 그런데 SQL Injection을 막기위해 WebKnight같은 웹 방화벽만으로 안전할까? 내 생각에는 안전하다고 생각하지 않는다. 하지만 현장에서 느끼는 문제는 이런 것이 아니다. 현장에서는...

- 페이지가 바뀌었는데 원상복구를 해도 자꾸 바뀐다.
- 사용자들이 올리는 글 때문에 짜증이 만땅된다.

이게 사실 가장 큰 스트레스의 이유다. DB 정보야 빠져나가면 그만이다. 누가 대대적으로 해킹해서 팔았다고 광고하지 않는 이상 스트레스를 받을 이유가 없다. (사실 이런 해커가 나오면 사이버 수사대에 신고해버리면 끝이다) 해킹 당한건 사실이고 이미 당한걸 어쩌겠냐? 잘 얼버무리든 다시 만들든 공지를 올리든 이번 한껀만 크게 잘 처리하면 되는거다. (물론 이미 당했다면 그 책임은 져야하는 것이 당연하다. -_-;)

그러면 현장에서 느끼는 이 짜증을 어떻게 막아야 할까?

옛날부터 내려오는 보안 수칙에 이런게 있다.

최소한의 프로그램만 설치한다.
데이터베이스는 사설망으로 바꾼다.

대부분의 업체들이 위 수칙은 잘 지키고 있다. 적어도 알고 있는 범위 내에서는 말이다. 근데 막상 사용해보면 DB를 사설망으로 바꿔봤자 소용이 없다. 위에 나온 수칙 중에 있는 DB를 사설망으로 바꾼다는 내용의 실제 중요한 핵심은 바로 DB와 웹서버의 연결고리를 끊는 것이다. 일단 정상적인 서비스를 위해서 MS-SQL과 IIS의 연결은 끊을 수 없다. 하지만, 다른 부분은 과연 신경쓰고 있을까? 예를 들면 다음과 같은 부분이다.

관리자적 공유 폴더(c$, d$, e$...)는?
컴퓨터 IP만 치면 알 수 있는 공유폴더는?
내부에 활성화 시켜둔 FTP서버로 접근은?
telnet, ssh 같은 원격 접속은?
오류 발생시 이를 내부에서는 검출하고 외부에서는 보지 못하게 할 수 있는가?

혹시 이런 부분이 문제가 된다고 생각해 본적은 없는가? 실제 SQL Injection뿐만이 아니라 해킹에서는 이런 부분을 이용한다.

자자~~ 오늘도 졸립다. 다음에 계속 쓰도록 하자~.

Security, SQL Injection, WebKnight, 보안, 웹서버해킹, 웹해킹

트랙백 1 Comment 2

Trackback : http://www.daegul.com/trackback/280

Subject SQL Injection을 막는 방법 #1
Tracked from 공부하세요. 2006/05/26 11:38
SQL Injection은 웹의 취약점으로 생긴다고 알고 있다. 이 SQL Injection은 그렇다. 분명한 취약점이다. 이 취약점이 문제가 되는 것은 정보가 빼

elca 2006/05/23 11:15
^^
다음글이 기대됩니다..
- 데굴대굴 2006/05/23 20:49
  될 수 있으면 이런 기술 문서 계열(이벤트 뷰어 제외)은 일주일에 하나씩은 올려볼려고 노력하고 있습니다.
  
  하루에 30분. 오래 걸려도 1시간이면 족하니까요. 다음 문서는 수요일 오후로 잡혀 있습니다. :)