빠른 배경 : 우리는 웹 애플리케이션 용 폼 빌더를 생성합니다. 작성자의 목표는 관리자가 페이지에 양식을 신속하게 추가/수정할 수있게하는 것입니다. 이 양식으로 수집 된 데이터를 보고서에서 쉽게 검색 할 수 있도록 응용 프로그램에서 사용자 입력 데이터를 보유하는 각 양식에 대한 테이블을 작성하도록 결정했습니다.CREATE TABLE 문에서 SQL 데이터 유형 이스케이프
보안을 염두에두고 우리의 테이블 이름과 열 이름은 모두 올바르게 이스케이프되고 적절한 따옴표로 묶여 있습니다 (MySQL의 경우 역 인용 부호). 그러나 CREATE 문에서 데이터 유형에 대한 이스케이프 또는 인용을 알지 못합니다. 더 나은 색인 및 검색을 위해 다른 데이터 유형을 고려할 수 있기 때문에 양식 작성/수정시 동적으로 결정됩니다.
현재 루트은 우리가 지원하는 가능한 데이터 유형을 허용 목록에 추가하고 임의의 크기 입력을 숫자로 강제 설정하는 것입니다. 이런 방식으로, 어떤 악의적 인 코드라도 BLOB 컬럼을 생성 할 수없고 "128"의 VARCHAR에 대한 크기를 전달할 수 없습니다; DROP DATABASE; " 128 또는 0으로 변환 될 것입니다 (PHP가 문자열을 숫자 변환으로 처리하는 방법을 지금 잊어 버렸습니다).
몇 가지 의견을 보내고 싶습니다. 적절한 보호 수단이라고 생각하십니까? 적절한 따옴표로 테이블 이름을 둘러싼 것과 비슷한 SQL을 작성할 수있는 방법이 있습니까?
또한 누구나 데이터 유형 크기에 어떤 위험이 있는지 생각할 수 있습니까? 나는 많은 공간을 차지하면서 잠재적으로 문제가 발생할 것으로 예상하지만, 보안은 전혀 없다.
예, 우리는 일종의 2 단계 번역 및 santizing/securing을하고 있습니다. 사용자는 간단한 데이터 유형으로 표시되며 양식 빌더는이를 임의의 표현으로 변환하고 데이터베이스 코드는 실제 SQL로 변환합니다. 예 : 사용자가 ** MONEY ** 유형의 필드를 만드는 경우 Form Builder가이를 ** DECIMAL, 12,2 **로 변경하고 데이터베이스가 DECIMAL (12,2) **로 변경합니다. – Chris
질문이 업데이트되었습니다. 음수, 0 또는 큰 데이터 크기와 관련된 문제가 있습니까? 0 또는 음수가 SQL 오류를 생성하고 큰 크기로 인해 부 풀릴 수 있지만 보안 문제는 없을 것으로 예상됩니다. – Chris
char 및 varchar를 특정 최대 크기로 제한하고 텍스트가 너무 커질 경우 MEDIUMTEXT 및 LONGTEXT로 자동 이동합니다. 또한 사용자가 highsize 필드를 많이 사용하는 것 같다면 양식 작성기에서 경고를 구현할 것입니다 ... –