테이블에서 보통 특정 컬럼에 auto_increment 처리해서 자동으로 증가하게 할 경우 중간에 값이 삭제 되었을때
예로 3번째 게시글이 삭제 될 경우 1, 2, 4, 5, 6 -> 처럼 3이 빠진 결과를 받게 되어 리스트에 번호로 사용하기 어럽다.
따라서, 임의로 번호를 붙여서 받아 오는 방법을 살펴 보자
set @i := 0;
select (@i := @i + 1) as num, * from board;
첫줄은 초기값이나 1부터 출력 되게 하려면 0을 입력 해두면 된다.
MySQL 설치하면서 비번을 잘못 입력(오타)하거나 기존 root 개정을 잊어 버린경우 다시 설치 하지 않고 비번만 변경할수 있습니다.
기존 MySQL 프로세스 종료하고 안전모드로 접속한후에 개정 테이블(user)에서 root 패스워드를 변경하는 방법입니다.
# MySQL 프로세스 죽이기
/etc/init.d/mysqld stop
killall mysqld
# MySQL 안전모드 접속후 root 비번 변경
cd /usr/local/mysql/bin
./mysqld_safe --skip-grant &
use mysql;
update user set password=password('비밀번호') where user='root';
FLUSH PRIVILEGES;
exit;
# 접속확인
mysql -uroot -p mysql
비번 입력후 mysql> 접속이 잘되면 성공입니다.
Aapache 2.x, PHP 5.x, MySQL 5.x 설치후 서버 이전을 끝내고 사이트 접속해보니 한글이 모두 ㅁㅁㅁ 특수기호들로 깨져 버리더군요.
원인을 알아 보니 mysql 기본 설치시 기본 문자셋이 utf8이 아니라서 생긴 문제 이더군요.
웹소스는 utf8 이며 기존 DB 자료 역시 utf8인데 mysql 기본 문자셋은 다른 문자로 되어 있어서 생긴 문제 였습니다.
다행이도 해결 방법이 mysql 다시 설치 하는 것이 아니라 /etc/my.cnf MySQL 설정 파일만 수정해 주면되었습니다.
자신의 기본 문자셋이 어떻게 되어 있는지 확인 해 보실려면 mysql 접속후 다음과 같이 확인 해 보세요!
mysql> SHOW VARIABLES LIKE 'character_set%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
이와 같이 latin1 등의 문자셋으로 설정 되어 있음을 확인하실 수 있습니다.
설정파일 수정은 /etc/my.cnf 파일을 수정 하시면 되며, 각 [항목] 바로 아래에 문자셋 설정을 추가 해주시면 됩니다.
# vi /etc/my.cnf
[client]
default-character-set=utf8
[mysqld]
init_connect='set names utf8'
character-set-server=utf8
default-collation=utf8_unicode_ci
skip-character-set-client-handshake
character-set-filesystem=utf8
default-character-set=utf8
[mysqldump]
default-character-set=utf8
[mysql]
default-character-set=utf8
위와 같이 추가하고 저장후 mysql 데몬을 다시 실행 해 보시면 아래와 같이 문자 기본셋이 변경 되었음을 확인 하실 수 있습니다.
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
사이트 접속해보니 이제 정상으로 한글이 보이는 군요.
등록 및 수정 등 쿼리 전송시 한글 처리는 잘되는지 아직 안해봤음 ^^
어느날 갑자기 MySQL 테이블 하나를 읽을려고 할때 다음과 같은 메시지가 나타날 경우
SQL Error: Can't open file: 'sessions.MYI'. (errno: 145)
테이블이 오류가 난것입니다.
원인은 하나의 테이블에 지속적으로 접속자가 너무 많이 connection이 된 경우 혹은 MySQL 기록중에 DB서버가 강제 종료 혹은 리부팅 되는 경우 깨지는 경우가 종종 발생 합니다.
이처럼 비정상적으로 종료된 테이블인 경우 마지막 처리 과정을 복구해서 정상 동작 하도록 하는 명령어가 있습니다.
먼저 해당 테이블 DB에 접속합니다.
mysql -u아이디 -p db이름
비번 :
repair table tablename; 입력 혹은 그냥 엔터
또는 간단하게 한줄로
mysql -u아이디 -p비번 db이름 repair table 테이블명
SQL 2000 Server 서비스 팩3,4 설치시 오류 대처방법
스크립트 실행 중 오류 발생 '80sp1-tools.sql (1)'
1. 쿼리분석기로 SQL Server 에 접속한다.
2. DBCC CHECKDB('dbname', NOINDEX) 로 지정한 데이터베이스에서 모든 개체의 할당과 구조적 무결성을 검사한다.
NOINDEX - 시스템 테이블이 아닌 테이블의 클러스터되지 않은 인덱스를 검사하지 않도록 지정한다. NOINDEX는 사용자 정의 테이블의 클러스터되지 않은 인덱스를 검사하지 않으므로 전체 실행 시간이 줄어든다. DBCC CHECKDB에서 모든 시스템 테이블 인덱스를 검사하므로 NOINDEX는 시스템 테이블에 어떤 영향도 주지 않는다.
-------------------------------------
NOINDEX 에 쓰일 수 있는 다른 옵션들 ↓
REPAIR_ALLOW_DATA_LOSS - REPAIR_REBUILD에서 수행하는 모든 복구 작업을 수행하며 할당 오류, 구조적 행 오류나 페이지 오류, 손상된 텍스트 개체 삭제를 수정하기 위한 행과 페이지의 할당 및 할당 취소가 포함된다. 이러한 복구를 할 경우 일부 데이터가 손실될 수 있다. 복구 작업은 사용자가 변경 사항을 롤백할 수 있도록 사용자 트랜잭션 내에서 수행된다. 복구가 롤백되어도 데이터베이스에는 오류가 그대로 포함되므로 백업에서 데이터베이스를 복원해야 한다. 제공된 복구 수준 때문에 오류 복구를 생략한 경우 해당 복구에 종속적인 모든 복구도 생략된다. 복구를 완료한 후 데이터베이스를 백업한다.
REPAIR_FAST - 클러스터되지 않은 인덱스의 별도 키를 복구하는 것과 같이 사소하고 시간이 소요되지 않는 복구 작업을 수행한다. 이러한 복구는 데이터 손실의 위험 없이 빨리 실행할 수 있다.
REPAIR_REBUILD - REPAIR_FAST에서 이루어지는 모든 복구 작업을 수행하고 인덱스 다시 작성과 같이 시간이 소요되는 복구를 포함한다. 이러한 복구는 데이터 손실의 위험 없이 실행할 수 있다.
-------------------------------------
3. 검사하여 오류가 발생하는 데이터베이스를 위의 옵션으로 적절히 사용하여 복구한다.
4. 이때 단일사용자 모드로 설정해야 한다.
sp_dboption dbname, single, true
5. 복구되면 단일사용자 모드 해제한다.
sp_dboption dbname, single, false
6. 서비스 팩을 다시 설치한다.
SQL은 Structured Query Language의 표준이며, 사용자에게 데이터 베이스를 접근 할 수 있게 해준다. 현재 대부분 SQL99가 SQL Language의 표준이다. SQL은 DB에 대한 Query를 실행 시킬 수 있고, DB로부터 수정/검색/삽입/삭제/업데이트 할 수 있다.
SQL Language에는 많은 다른 버전이 있지만, 거의 비슷한 키워드의 명령어를 지원한다.(예: SELECT,UPDATE,DELETE,INSERT,WHERE 등) 대부분의 SQL 데이터베이스 프로그램은 SQL 표준 외에 그들 자신만의 확장된 언어를 가지고 있다. 관계형 데이터베이스는 하나 또는 그 이상의 테이블을 포함하고, 각각의 이름을 가진다. 테이블은 레코드단위로 데이터를 가진다.
예) 아래의 테이블 명은 “user”이고 행과 열로서 데이터가 저장된다.
|
userID |
Name |
LastName |
Login |
Password |
|
1 |
John |
Smith |
jsmith |
hello |
|
2 |
Adam |
|
adamt |
qwerty |
|
3 |
Daniel |
Thompson |
dthompson |
dthompson |
▪ 데이터 베이스로 SQL Query를 보내서, 결과 값을 되돌려 받을 수 있다. 위의 테이블을 이용해서 다음과 같은 Query를 사용 할 수 있다.
a) SELECT LastName FROM users WHERE UserID = 1;
b) 결과 값(레코드 셋)
|
LastName |
|
Smith |
▪ Data Manipulation Language(데이터 조작어) : SELECT ,UPDATE ,INSERT INTO DELETE와 같이 데이터를 조작하는 언어를 뜻 한다.
▪ Data Definition Language(데이터 정의어) : 데이터 정의어로서 데이터베이스 테이블을 생성/삭제 하고, 인덱스(키)를 정의, 테이블 사이의 관계를 설정 하며, 데이터베이스 테이블 사이의 제약 조건을 설정한다.
예) CREATE TABLE, ALTER TABLE, DROP TABLE등과 같은 구문
대부분의 SQL 데이터베이스들은 관계형 데이터베이스 기반이다. SQL Injection을 위한 중요한 사실은 관계형 데이터 베이스는 Codd의 12법칙 중에서 4법칙을 확실히 따르고 있다는 것이다. 제4법칙 : 메타데이터(데이터베이스에 관한 데이터)는 반드시 일반적인 데이터들처럼 데이터베이스에 저장 되어야 한다. 또한 데이터 베이스구조는 SQL Query문을 통해서 읽거나 수정 할 수 있다
데이터베이스 엔진에 삽입하는 SQL 명령들은 애플리케이션을 통해 이용 가능하다. 이것은 오늘날의 대부분의 공통적인 웹사이트의 취약점 중에 하나이다. 이것은 Web Application의 발전에 따른 것이고, DB나 Web Server의 문제가 아니다. 대부분의 프로그래머들은 여전히 이 문제를 인식하지 못한다. 많은 지침서와 데모 템플릿이 취약 하다. 심지어 인터넷에 게시된 많은 솔루션들도 좋지 못하다. 모의 해킹을 의뢰한 60%가 넘는 고객의 시스템이 SQL Injection에 취약하다는 결과를 내놓는다. 대부분의 SQL 데이터베이스들 그리고 프로그래밍 언어들은 잠재적으로 취약하다. DBMS는 MS SQL Server, Oracle, MySQL, Postgres, DB2, MS Access, Sybase, Informix 등이 이다.
애플리케이션을 통한 데이터베이스 접근 방법
▪ Perl and CGI scripts
▪ ASP, JSP, PHP
▪ XML, XSL and XSQL
▪ no_javascript
▪ VB, MFC, and other ODBC-based tools and APIs
▪ DB specific Web-based applications and API’s
▪ Reports and DB Applications
▪ 3 and 4GL-based languages (C, OCI, Pro*C, and COBOL)
|
SELECT * FROM users WHERE login = 'victor' AND password = '123' |
1) ASP/MS SQL Server 로그인 문법
|
var sql = "SELECT * FROM users WHERE login = '" + formusr + "' AND password = '" + formpwd + "'"; |
a)문자를 통한 Injection
|
formusr = ' or 1=1 – – formpwd = anything |
b) 최종 쿼리 결과
|
SELECT * FROM users WHERE username = ' ' or 1=1 – – AND password = 'anything' |
2) PHP/MySQL 로그인 문법
|
$sql = "SELECT * FROM clients WHERE account = $formacct AND pin = $formpin"; |
a) 숫자 입력 필드에 삽입
|
$formacct = 1 or 1=1 # $formpin = 1111 |
b) 최종 쿼리 결과
|
SELECT * FROM clients WHERE account = 1 or 1=1 # AND pin = 1111 |
취약점은 어디든지 생길 수 있고, 아래의 사항을 모두 체크 해야 한다.
a) 웹 폼의 필드
b) URL 쿼리 스트링의 스크립트 파라미터 값
c) 쿠키 또는 히든 필드에 저장된 값
d) 아래의 문자열을 모든 입력 필드에 테스트해야 한다.
|
▪ 문자 : ' " ) # || + > ▪ SQL Query 명령을 공백(구분자)과 같이: %09select (tab%09, carriage return%13, linefeed%10 and space%32 with and, or, update, insert, exec) ▪ 지연 쿼리:' waitfor delay ' |
아래의 항목들을 알아내려고 시도해야 한다.
a) 출력 메커니즘 연구하기
1. 웹 애플리케이션의 쿼리 결과 값을 이용한다.
2. 에러 메시지 : 에러 메시지로부터 입력 값 검증을 유추 할 수 있다.
3. Blind SQL Injection : 시간의 지연 또는 에러 메시지를 사용하여 정보를 추출한다. Blind SQL Injection은 SQL Injection과 거의 비슷하지만, 많은 Query를 통해서 정보가 수집해야 되고, 또한 필드 값이나 테이블명과 같은 정보를 추측해야 하므로, 매우 느리고 더욱 어렵다.
■ 에러 메시지를 통해서 정보 추출 하기
i. 그룹 핑 에러
|
' group by columnnames having 1=1 - - |
ii. 타입의 불일치
|
' union select 1,1,'text',1,1,1 - - ' union select 1,1, bigint,1,1,1 - - |
iii. 더 좋은 방법으로, DB에서 하위 Query를 이용 한다.
sql 재시작해도 안되는것이었다.
새로 설치한 서버는 웹과 DB를 하나의 서버에 설치 했기에
혹시나해서 sql 연결구문에서 ip를 127.0.0.1 로 바꿨더니 접속이 된다.
OTL 헐..
MSSQL2008이 나왔는데 MSSQL2005를 붙잡고 고생하고 있다. ㅋㅋ
MYSQL 서비스 시작시 다음과 같은 오류 발생 후 서비스가 시작되지 않는 경우
STOPPING server from pid file /usr/local/mysql/var/서버명.pid
DB Data 폴더에 있는 에러 로그를 확인해보세요!
cat /usr/local/mysql/var/서버명.err
(var OR data)
~~~~ 오류 내용 ~~~~~
090406 09:16:21 mysqld started
InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Error_creating_InnoDB.html
090406 9:16:22 Can't init databases
090406 9:16:22 Aborting
090406 9:16:22 InnoDB: Warning: shutting down a not properly started InnoDB: or created database!
090406 9:16:22 /usr/local/mysql/libexec/mysqld: Shutdown Complete
090406 09:16:22 mysqld ended
이와 같은 오류 메시지가 나온다면 저의 경우 로그파일을 모두 제거후 복구 되었습니다.
아마도 로그 파일이 꼬였던것 같네요
로그 파일은 삭제 해도 상관없다고들 하더군요..^^
rm 서버명-bin.001 ...
rm 서버명-bin.index
rm 서버명.pid
참고로, 서버 명에 따라 파일명이 다르게 표시됩니다.
동일한 증상이길 바라며 해결 하시길 바랍니다.
그리고, 간혹 /tmp/mysql.sock 파일 문제로 해당 파일을 제거 후 해결 되기도 한다는 군요
참고하세요!
에러 메세지
Error 1016 : Can't open file: '테이블.MYI'. (errno: 145)
복구 방법
명령어 : mysqlcheck -u계정명 -p --auto-repair -B DB명
Enter password : 비밀번호
mysql> repair table 테이블명;
+---------------------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+---------------------+--------+----------+----------+
| 테이블명 | repair | status | OK |
+---------------------+--------+----------+----------+
1 row in set (34.24 sec)
DB injection 공격?
구글에서 <script src= 0.js 라고 검색하면 놀랄 정도로 많은 사이트들이 DB 공격을 받았음을 확인 하실 수 있을겁니다.
제가 관리하는 사이트 또한 위와같은 스크립트 삽입되어 수많은 사이트를 찾아 다니며 복구하고 나름대로 보안하는 방법을 접하게 된 것을 올려 봅니다.
1. 공격 유형 :
SQL injection 홈페이지 상의 DB사용하는 페이지를 공격 즉, 웹소스 취약한 곳을 통해 DB를 공격.
특수 코드 삽입해서 DB에 스크립트를 삽입하여 접속하는 사용자에게 악성코드를 설치하는 유형.
2. 조치 시 주의 사항
참조 : http://swbae.egloos.com/1747128
1) 홈페이지 변조를 통해 악성코드 링크를 삽입한게 아니라, SQL injection 기법을 이용해 DB 컨텐츠에 삽입한 것입니다.
2) 조치 시 DBA 의 도움을 받는게 좋습니다.
3) 공격 때문에 기존의 데이터가 일부 덧씌워져 변경되었을 수 있습니다. 이럴 땐 백업의 도움을 받아야 겠지만, 일부 데이터의 유실은 어쩔 수 없을 듯...
4) 근본 원인은 사이트가 SQL injection 공격에 취약하게 개발되어 있어서 그렇습니다. 공격 포인트를 파악해서 외주개발 업체, 혹은 내부개발팀을 통해 소스를 수정하세요.
5) 소스를 수정할 수 없는 경우 웹 방화벽이 도움이 될 수도 있습니다. 그러나, 제품 도입시 면밀히 검토하실 필요가 있습니다. 단순 패턴 매칭 형태를 사용해서, 보유패턴과 1byte 만 틀려도 탐지 못하는 제품이 몇 개 있더군요.
3. 공격으로 생긴 DB table 삭제
comd_list 테이블 삭제
ahcmd 테이블 삭제
foofoofoo 테이블 삭제
Reg_Arrt 테이블 삭제
comd_list 테이블 삭제
D99_CMD 테이블 삭제
D99_TMP 테이블 삭제
Kill_kk 테이블 삭제
jiaozhu 테이블 삭제
4. 삽입 스크립트 제거 복구
DECLARE @T varchar(255), @C varchar(255);
DECLARE Table_Cursor CURSOR FOR
SELECT a.name, b.name
FROM sysobjects a, syscolumns b
WHERE a.id = b.id AND a.xtype = 'u' AND
(b.xtype = 99 OR
b.xtype = 35 OR
b.xtype = 231 OR
b.xtype = 167);
OPEN Table_Cursor;
FETCH NEXT FROM Table_Cursor INTO @T, @C;
WHILE (@@FETCH_STATUS = 0) BEGIN
EXEC(
'update ['+@T+'] set ['+@C+'] = left(
convert(varchar(8000), ['+@C+']),
len(convert(varchar(8000), ['+@C+'])) - 6 -
patindex(''%tpircs<%'',
reverse(convert(varchar(8000), ['+@C+'])))
)
where ['+@C+'] like ''%<script src=http://s.ardoshanghai.com/s.js></script>'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;
'스크립트 부분은 삽입된 스크립트를 입력
5. 보안 적용 1 - MSSQL 메모리에서 위험한 sp들을 내린다.
보안상 위협이 될 수 있는 개체들에 대하여 일반 사용자 그룹의 사용권한을 제한한다.
참조: http://blahblah.springnote.com/pages/351077
SP 등록해제는 위험을 감안해야 하므로 메모리에서만 내린다. 단점, 재부팅되거나 DB 재시작시 다시 아래 쿼리 실행 할것!
dbcc xp_cmdshell(free)
dbcc xp_dirtree(free)
dbcc xp_regdeletekey(free)
dbcc xp_regenumvalues(free)
dbcc xp_regread(free)
dbcc xp_regwrite(free)
dbcc sp_makewebtask(free)
6. 보안 적용 2
무엇보다 DB 인젝션이 발생한 원인인 로그인, 회원가입, 게시판 등 사용자가 DB를 접하게 되는 소스 개발시 특수 문자 보안 적용 안된 경우가 가장 유력하다.
로그인, 회원가입, 아이디 비번찾기, 게시판 등이 개발자가 개발하면서 DB를 공격할만한 특수 문자에 대한 차단 기능을 적용하지 않은 문제로 판단됨. 소스를 모두 개선 해야함.
보안참조 : http://magic.littleworld.net/ai/kmod.asp?no=327&isn=&mymsg
위 글은 세이박스에서 작성한 글입니다.
출처를 적어 주시고 많은 국내 사이트들이 공격을 받고 있으니 도움이 되기 위해 많이 많이 올려주세요! ^^
출처 : 세이박스 http://saybox.tistory.com/453
mysql datadir 로 지정되어있는 폴더를 정확히 확인하신 후 아래와 같이 하시기 바랍니다.
datadir 이 /usr/local/mysql/var 일 경우 예입니다.
/usr/local/mysql/share/mysql.server stop
/usr/local/mysql/var/ 디렉토리에 bin-log 파일을 삭제하시면 되는데 형식은
아래와 같습니다.
-bin 패턴이 불어있는 파일을 rm 으로 삭제하시기 바랍니다.
rm -f *-bin*
/usr/local/mysql/share/mysql.server start
위에 있는 글중에서
/usr/local/mysql/share/mysql.server stop
부분과
/usr/local/mysql/share/mysql.server start
부분에 있는 명령어들은 설정에 따라 틀릴 것이다.
무조건 따라 하다간 서버가 남아 나질 않을 것이니 자신의 서버에 맞게 명령어를 내리자
그리고
rm -f *-bin*
부분에서 *-bin*은 문제가 있는명령어이다
보통 도메인-bin.00001같이 되어 있는것을 저렇게 지울수도 있지만
현재 사용중인 도메인-bin.index 파일도 삭제 될수 있기 때문에
들어가서 하나하나 삭제 하는것이 낳을 것이다.
잠깐!! 문제가 발생 하였다.
현재 *-bin* 파일의 index 파일의 안을 vi 롭 보면 지워야할 파일이름이 있을 것이다.
이와 같은 경우 index 파일의 안의 이름을 지워줘야 정상적으로 mysql이 작동 될것이다.
usr/local/mysql/bin/mysqlbinlog -uroot -pxxxx -r host명-bin.001 > test.txt
20090223_우편번호(기존형태).zip
댓글을 달아 주세요