내가 작업하고있는 프로젝트에서 또 다른 어리석은 sanitized-at-all sql 삽입 결함에 (우연히) 우연히 만났습니다 ... 너무 피곤합니다.
나쁜 SQL 문을 제거하고 가능한 경우에 준비된 문을 적용하는 방법에 대한 조언이 있습니까? 지금은 준비된 문장을 시행하는 방법
REVOKE DarnInlineDataStatements ON * TO xyz과 같은 솔루션을 선호 할 것입니다. 정적 코드 분석 도구를 사용하여 이러한 사항을 찾아 낼 수 있습니까? 또는 무엇이든 다른 사람에게 추천 하시겠습니까?
정적 코드 분석 도구를 이미 사용하고 있다면 Connection.prepareStatement 대신 Java 월드 Connection.createStatement에서 특정 메소드의 사용법을 찾도록 구성 할 수 있습니다.
나는 더 나은 접근법은 연결을 사용하여 동적 SQL을 생성하는 부작용에 대해 팀을 교육하는 것이라고 생각합니다. 코딩 표준 문서에 추가해야합니다!
SELECT, INSERT, UPDATE, DELETE와 같은 일반적인 T-SQL 구문을 코드베이스에서 검색 할 수 있습니다
Visual Studio 2008 Team System을 사용하는 경우 일부 SQL 문제를 확인하는 기본 제공 코드 분석 규칙이 있습니다. 그렇지 않으면 무료 FxCop이 있습니다.
소프트웨어에서 매개 변수화되지 않은 모든 쿼리를 쉽게 찾을 수 있기를 바랍니다. PHP의 PDO 나 Perl의 DBI와 같은 대부분의 데이터베이스 액세스 레이어는 SQL을 실행할 때보 다 쿼리를 준비 할 때 다른 호출을합니다. 이러한 호출이 무엇인지 파악하고 코드를 검색하면 좋은 시작을 얻을 수 있습니다. Linux를 사용하고 있다면 grep은 친구입니다.
거기에서 그들을 고정시키는 것은 충분히 쉬울 것이다 (나는 희망한다). 프로젝트의 크기를 모르지만 액티브 레코드/DataMapper/테이블 행 게이트웨이와 같은 일반적인 패턴을 기반으로 쿼리를 일반적인 장소에 배치하거나 개발할 수 있습니다.
나는 자동으로 실행하는 좋은 방법이 있다고 생각하지 않습니다. 아마도 당신은 동료들과 마음을 만날 필요가있을 것입니다. 인라인 SQL이 좋지 않습니다. 이야기의 끝. 당신이 지도자라면, 나는 위임 명령이 될 것이라고 생각합니다.
내가 일하는 사람들은 계속이 SQL 래퍼를 작성합니다. 나는 포장지를 싫어한다! Perl DBI를 왜 포장해야합니까? 왜? 왜? 그것은 이미 WRAPPER입니다! –
SQL을 저장 프로 시저로 이동하면 응용 프로그램 사용자에 대해 SELECT, CREATE, ALTER, UPDATE, DELETE, DROP 등의 사용 권한을 사용하지 않도록 설정하고 EXEC 액세스 만 허용 할 수 있습니다. 그건 SQL Server를 가정하지만, 나는 오라클/MySQL은 비슷한 설정을 허용 확신 해요.
이렇게해도 준비된 문이 보장되는 것은 아니므로 안전하지 않은 방식으로 저장 프로 시저를 호출 할 수 있습니다. 그러나 많은 저장 프로 시저를 사용하지 않았다면 올바르게 코딩되지 않은 곳을 찾을 수 있습니다. 무엇이든 놓치면 SQL 주입 공격이 성공하기 어렵게 만듭니다.
SP 중 동적 SQL을 사용하는 경우 (일부는 저주로 간주하고 유효한 사용 권한이 있음을 알게 됨) EXEC 권한 만 남겨두면 SQL 주입 공격으로부터 사용자를 보호 할 수 없습니다. –
응용 프로그램에서 코드를 데이터베이스 서버로 직접 보내지 않고 중간 계층을 통해 보내도록하십시오. 그것은 DB에 보내지는 것이 무엇이든간에 쉽게 파싱 할 수 있고 그것에 대한 제약을 적용 할 수 있습니다. 예를 들어, 모든 SQL 코드가 과 하나의으로 구성되도록하고 하나 이상의 명령문을 거부하고 두 개 이상의 명령문이 있으면 첫 번째 명령문 만 실행하십시오.
기본 SQL 주입 공격은 다음과 같은 코드를 포함 :
DECLARE @SQL VARCHAR(4000), @Table VARCHAR(50)
SET @Table='Employees' -- Imagine this actually comes as a parameter from app
SET @SQL='SELECT * FROM '[email protected]
EXEC(@SQL)
은 공격자가 문자열을 전달할 수있다 "SYSTABLES을 '; UPDATE는 BankAccount SET 돈 = 돈 + 10000 WHERE AccountCode = 12345; DROP의 표 AuditTrails;" DB에 - 그것은 재앙적인 영향을 줄 것입니다.
중간 계층에서 문자열에 대한 최소 구문 분석을 수행하면 SQL 주입 공격 중 가장 간단한 것으로부터 보호받을 수 있습니다. 다른 사용자의 경우 중간 계층에 추가 할 수 있습니다 (결과 캐싱, 대역폭 조절 등도 처리 할 수 있습니다)
에이 있어야 앱에서 둘 이상의 SQL 문을 전달할 수 있습니다. 잘못된 일을하고 스토어드 프로 시저에 로직을 캡슐화하거나 미들 티어 자체에서 최소한을 캡슐화해야합니다.
이 시점에서 (그리고 내 현재의 분위기) 나는 postgres, mysql, 또는 어쩌면 _finding_ 그런 프로젝트에서 실제 SQL 파서를 조사하고 수정하는 것에 대해서 생각해 보았다.) 거의 모든 것을위한 프로젝트가있다. – VolkerK
이것은 잘못된 것입니다. 자신이 끈을 살균하려고하는 경우 이미 잃어버린 것입니다. –
DB에 직접 쿼리를 보내는 것은 나쁜 생각입니다. 중간 계층을 통해 모든 것을 처리하면 실제로 보안에 도움이 될 수 있습니다. 여기서 생각하는 것은 문자열을 위생적으로 처리하는 것이 아니라이 유형의 SQL 주입 공격으로 인한 피해를 줄이거 나 무효화하는 것입니다. 다른 공격에는 다른 보호 체계가 필요합니다. –
감사합니다. 내 todo 목록에 FxCop을 추가했습니다.) – VolkerK