Microsoft SQL Server 데이터베이스를 구동하는 Delphi 2006 응용 프로그램이 있습니다.Delphi 응용 프로그램 내에서 문자열 보호
우리는 실행 파일을 16 진수 편집기로로드하고 SQL을 수정할 수있는 취약점을 발견했습니다. 사람이이 있는가,
우리의 장기 계획은 저장 프로 시저를 CLR이 SQL을 이동하는 것입니다 그러나 이것은 여전히 SQL을 2000
우리는 문자열을 난독에 대해 생각했습니다를 사용하는 고객의 많은부터 떨어져 몇 가지 방법이있다 이 작업을 수행하는 도구에 대한 권장 사항은 무엇입니까?
더 나은 해결책이 있습니까, 코드 서명이 있습니까?
모든 쿼리를 암호화하여 리소스 파일에 저장할 수 없습니까? 런타임 중에 먼저 다음을 수행해야합니다.
그러면 이전과 같이 쿼리를 실행하면됩니다.
큰 문제는 아닙니다. 물론 일부 리소스/폴더에 쿼리를 저장하지 않는 경우 응용 프로그램을 약간 리팩토링해야합니다. 그러나 어쨌든 체계적으로 보관해야합니다. 따라서 하나의 돌로 2 마리의 새를 치게 될 것입니다 ;-)
문자열 암호화의 경우 DCPCrypt라는 무료 라이브러리를 사용할 수 있습니다.
이것은 갈 길이 멀고 DCPCrypt를 이미 사용하고 있으므로 구현하기가 너무 까다 롭지 않습니다. 제안 해 주셔서 감사합니다. – Mattl
사용자가 취약점을 재배치하고 수정하는 것이 아닙니다. 디버거는 16 진수 편집기처럼 사용하기 쉽습니다. –
네,하지만 그는 기분이 좋아질 것이므로 문제가 해결됩니다. 헥스 에디터 기반 공격의 실제 위협에 대한 어떠한 증거도 보지 못했습니다. 그래서 아마 고객이 자신의 "미니 감사"를 수행 할 수있을만큼 똑똑한 IT 직원을 갖고 있으며,이를 유순하게 준수하는 공급 업체에게 문제로 제안하는 경우 일 것입니다. –
나는 누군가가 16 진수 편집기를 사용하여 자료를 수정하는 것을 어렵게 만드는 exe packer을 사용해야한다고 생각합니다.
보증인은 디 패킷커가 없음을 알고 있습니까? –
다른 주석에서 말했듯이 디버거는 16 진수 편집기만큼 쉽게 사용할 수 있습니다. –
@ Marco van de Voort 그럼 완벽한 솔루션은 무엇입니까? – Sarfraz
포함 된 SQL이 해킹되는 경우 데이터베이스가 열려 있고 MSQRY32.EXE (MS Office) 사용자는 누구나 데이터를 가져올 수 있음을 의미합니다.
공급 업체 인 경우 클라이언트에서 CLR을 사용하도록 설정할 수 없습니다. 그렇다면 비 CLR 저장 프로 시저를 사용하고 버전 독립적 인 데이터베이스에서 권한을 수정하는 것이 어떻습니까?
실행하기 전에 exe를 암호화하거나 유효성을 검사하는 "보호"스위트가 있습니다. "암호화 exe"또는 "유효성 검사 exe"또는 이렇게 아마 도움이 될 것입 검색. 보통 그들은 payware이지만, $ 100 이하입니다.
원칙은 exe 패커와 동일하며 보안에 더 중점을 두는 것보다 비용이 많이 드는 안티 바이러스 추론 (anti-virus heuristics)이 때때로 반응하는 약간의 단점을 가지고 있습니다. 문제는 대부분의 exe 패커에게는 depackers가 있다는 것입니다.
나는 dinkeydongle의 제품을 사용하지만 하드웨어 동글에도 연결되는 종류이기 때문에 멀리있는 다리가 될 수도 있습니다.
우리의 소프트웨어는 종종 단일 컴퓨터의 많은 가상 머신에서 실행될 수 있으므로 동글을 사용할 수 없습니다. 우리는 또한 불법 복제에 대해 우려하지 않습니다. 이것은 우리에게 문제가되지 않습니다. 다른 것들 중에서 런타임 라이브러리에 문제가 발생할 수 있으므로 패커 사용에 너무 열중하지 않습니다. – Mattl
마찬가지로 동글이없는 비슷한 물건이 있습니다. 내가 하나를 사용하기 때문에 나는 단지 이름으로 빨리 올 수 없다. 그렇지 않은 경우 유일한 해결 방법은 모든 상수를 암호화하고 코드에서 수동으로 사용하기 전에 해독하는 것입니다. (아무도 프로세스의 메모리를 엿보지 않기를 바랍니다.) 런타임 라이브러리 요구 사항으로 인해 모든 CONST 세그먼트 암호화 도구가 실패합니다. –
완전히 보호 할 수는 없지만 "임시 공격"을 어렵게 만들 수 있습니다. 내가 사용하는 간단한 시스템은 ROT13과 비슷하지만 더 넓은 범위의 "ROT47"유형 시스템입니다. 코드는 다음과 같이 다네 다음
frmLogin.Caption := xIniFile.ReadString(Rot47('$JDE6>' {CODEME'System'}),
여기서 핵심은 내가 그것을 볼 수 있지만, 더 중요한 것은 내가 내 FinalBuilder에서 실행되는 유틸리티 수 모두 있도록 문자열을 포함하는 의견을 가지고 빌드 스크립트. 이를 통해 릴리스 코드에서 문자열이 항상 최신 상태인지 확인할 수 있습니다. 유틸리티는 행에서 {CODEME}을 찾고, 발견되면 적절하게 출력 할 데이터의 형식을 압니다.
그건 좋은 해결책이야, 너 스스로 유틸리티를 작성 했니? – Mattl
먼저 위협 분석을 수행하십시오. 누가 귀하의 취약점을 사용하고 있으며, 이것이 왜 문제가됩니까? 그에 따라 행동하십시오.
응용 프로그램이 win32이고 위협이있는 어린이들이 재미 만 있다면 무료 exe 패키지 (예 : upx)가 해결책 일 수 있습니다. .NET 응용 프로그램에서 서명이 원하는 것일 수 있습니다.
이상이 필요한 경우 비용이 많이 들고 응용 프로그램을 개발하는 것이 더 어려워 질 것입니다. 아마도 당신은 심지어 그것을 재구성 할 필요가 있습니다. 상업용 보호 체계 (동글 사용 가능) - 외부 하드웨어에 문자열을 저장하는 보호 체계. 하드웨어가 없으면 SQL 문자열이 없습니다. 그러나, 내가 말한대로, 그것은 더 비싸다.
네이티브 실행 파일에도 서명 할 수 있습니다. –
무뚝뚝 함을 드려 죄송합니다. 실행 파일에서 "보안"조치를 적용하려고 생각하는 경우 파멸합니다. 스크램블링 스키마는 평균 해커를 보유하지 않습니다.
앱 디자인 방법도 설명하지 않았습니다. 데이터베이스가 귀하에 의해 호스팅 되었습니까? 아니면 클라이언트의 구내에 있습니까? 후자의 경우 보안을 잊어 버리고 변호사를 고용하여 고객과의 기밀 유지 계약을 맺으십시오. 전자의 경우 저장 프로 시저를 사용하는 것이 가장 쉬운 방법입니다.
이것은 취약점이 아닙니다. 컴퓨터가 EXE를 로컬로 수정하는 데 취약한 경우 이는 사용자의 취약점입니다.
모든 EXE가 해킹 당할 수 있습니다. 누군가가 로컬 관리자 계정에 액세스 할 수 있으면 게임이 리소스 문자열에 가까워지기까지 오래 걸립니다.
DB 인터페이스를 저장 프로 시저로 이동하십시오. Normal regular stored procedures CLR없이 이미 검색어를 입력하면 큰 문제는 아닙니다.
몇 가지 이유로 T-SQL을 배우지 않으려면 모든 쿼리 문자열을 데이터베이스로 이동하고 응용 프로그램 단일 쿼리에 저장하십시오.이 목적은 데이터베이스에서 지정된 쿼리 ID로 SQL 코드를 읽는 것입니다.
인코딩 모든 트릭
은 문제를 많이 생산하고 있지만, 실제 보안을 제공하지 않습니다 해야 사용 가역 (문제의 성격에 의해 결정) 암호화 및 응용 프로그램 실행에 배치 디코딩을위한 모든 키 때문에 너무.응용 프로그램을 심층적으로 재구성해야하는 솔루션은 다중 계층 접근 방식을 사용하는 것입니다. 대부분의 SQL 코드는 응용 프로그램 서버 모듈에 있고 서버에있는 것은 클라이언트 측 exe.
악의적 인 사람이 EXE를 수정할 수있는 경우, 그 사람이 EXE를 얼마나 잘 보호하는지에 관계없이 이미 잃어 버렸습니다. 이것은 취약점이 아닙니다. 그것은 시스템에 물리적으로 액세스 할 수있는 사람이 자신이 관심있는 모든 것을 실행할 수 있다는 진술 일뿐입니다. –
또한 : 귀하의 "솔루션"을 문제에 맞게 수정하는 방법을 묻는 중일 수도 있지만 실제 문제에 대해서는 묻지는 않습니다. ** 데이터 **를 데이터베이스에서 보호하려고합니까? SQL Server에서이 작업을 수행하는 올바른 방법이 있으며 클라이언트를 제어하려고 시도하지 않습니다. 실제 필요 사항을 설명하기 위해 질문을 업데이트하십시오. –
먼저 데이터베이스 수준에서 적절한 권한을 설정하고 one-dbuser-does-all 접근 방식을 사용하지 않았 으면합니다. 사용자가 exe를 변경할 수있는 권한이 있으면 모든 데이터베이스 도구를 실행하고 원하는 모든 SQL을 사용할 수도 있습니다. –