주입 안전 호출

가 axpata 사업 커넥터를 통해 전화를 주입 안전한 방법이 있나요주입 안전 호출

string salesId = someObject.Text; 

IAxaptaRecord salesLine = ax.CreateRecord("SalesLine"); 
salesLine.ExecuteStmt("select * from %1 where %1.SalesId == '" + salesId + "'");

someObject.Text는 다음과 같이 설정되어있는 경우, 난에 X ++ 코드 주입 한 후 취약입니다 :

"SomeSalesOrder' || %1.SalesId == 'SomeOtherOrder"

쿼리 변수화 할 수있는 방법이 있나요, 또는 직접 X의 데이터 액세스 코드 ++을 모두 작성한 다음 COM에서 해당 전화를 더 나은 것입니까?

출처

2009-05-18 holz

당신이 모든 경우를 적용했는지 확인하는 방법은 없습니다 ...

은 대부분 잘못된 접근이다. Axapta 메서드 (매개 변수 포함)에 select 나 any를 쓰고 그 메서드를 호출해야합니다.

출처

2009-05-18 07:13:32

리터럴을 사용하지 않는다면 간단한 쿼리의 기본 동작은 안전한 것으로 간주되는 자리 표시 자 (매개 변수화 된 쿼리)를 사용하는 것입니다. 복잡한 쿼리 (조인)의 경우 조인에서 ForcePlaceholders 힌트를 사용하는 것이 유일한 방법입니다. –

-2

'to \' 등의 대체품을 사용해야합니다. ExecuteStmt를 사용

string salesId = someObject.Text.Replace("'", "\\'");

출처

2009-05-18 04:14:14

(string query, params object []) 이것은 변수에 대해 필요한 작업을 수행 한 후 (예 : 이스케이프) – holz

을 준뿐만 아니라 예를 들어 모든 가장자리 경우를 처리하기 위해 프레임 워크에 의해 처리 매개 변수화가 방법을 찾고 –

string.Format에서 예상 한 형식으로 쿼리를 받아 들일 수 있습니다. 전체 문제는 이스케이프 처리 중입니다. 바르게. 쿼리가 "select * from % 1.Id == {0}"(여기서 {0}은 int 여야 함), "42 || 1 == 1"이 전달되면, 당신이 준 방법으로 그것을 벗어났습니다. 여기에 x ++ 삽입의 모든 가장자리 사례를 알지 못하므로 자체 탈출 방법을 쓰고 싶지 않습니다. 왜냐하면 내가한다면, 나는 뭔가를 놓칠 가능성이 있으며, 너무 늦은 후에 만 그것에 대해서 알 수 있기 때문입니다. 이것은 기밀 정보가 많은 공개 웹 응용 프로그램을위한 것이므로 주입 위험이 100 %가되어야합니다. – holz

-2

목재,

당신은 forcePlaceholder 키워드와 함께 문을 SELECT 매개 변수화 사용할 수 있습니다. 이것은 X ++의 기본 동작이지만 복잡한 조인의 경우이 동작을 재정의 할 수 있으므로 forcePlaceholder 힌트를 암시 적으로 지정하는 것이 좋습니다.

매개 변수화 된 SELECT는 약간의 추가 오버 헤드가 발생하고 매개 변수의 실제 값을 최적화 할 수 없기 때문에 뷰 또는 axapta 쿼리를 대신 사용하는 것이 좋습니다.

감사합니다, Velislav Marinov

나는 당신이 ExecuteParametizedStmt '같은 것을입니다 IAxaptaRecord에 대한 확장 방법을 만들 수 있습니다 내가

출처

2009-05-18 20:36:33

'forceplaceholders'는 질문에 언급 된 문제를 해결하지 못합니다. 값으로 X ++에서 리터럴을 사용하더라도 커널에 의해 값이 인용되므로 문제가되지 않습니다. –

틀렸어. ForcePlaceholders는 매개 변수화 된 쿼리를 생성하지만 ForceLiterals는 SQL 삽입에 취약합니다. MS가 보안 백서를 확인하십시오. –

보안 백서 : http://download.microsoft.com/download/b/6/e/b6e77418-cde2-4ed4-a920-60d7f2d17757/Microsoft%20Dynamics%20AX%20Writing%20Secure%20X++%20Code.doc 문제는 비즈니스 커넥터를 통한 직접 SQL 사용에 관한 것이 었습니다. 이는 나쁜 것입니다. 'forceliterals' /'forceplaceholders'도 또 다른 문제입니다. Forceriteral은 커널 인용 부호가 우회 될 수있는 경우 문제가되며, 이는 반증하기가 어려울 수 있습니다. –

주입 안전 호출

답변

관련 문제