사용자의 의도적 인 잘못된 행동을 고려하면 과도하게 엔지니어링합니까?

사용자가 초래할 수있는 피해가 내 코드와 관련이없는 경우 사용자의 의도적 인 잘못에 대해 보호 기능을 추가하면 과도하게 엔지니어링됩니까?

명확히하기 위해 다음과 같은 간단한 JSON RESTful 서비스를 공개하고 있습니다.

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

이 서비스 자체는 브라우저를 통해 사용되는 것이 아니라 전화 응용 프로그램, 데스크톱 응용 프로그램 등과 같이 사용자가 제어하는 ​​타사 응용 프로그램에서만 사용할 수 있습니다. 또한 서비스 자체는 상태 비 저장 (즉, 세션 비 저장)이어야합니다.

인증은 SSL을 통한 기본 인증으로 수행됩니다.

다음과 같은 가능한 "유해한"행동에 대해 이야기하고 있습니다.

사용자는 브라우저에 GET URL을 입력합니다 (이유는 아니지만 ...). 브라우저는 기본 인증을 요청하고 처리 한 후 현재 브라우징 세션에 대한 인증을 저장합니다. 브라우저를 닫지 않고 사용자는 서비스에 POST를 만드는 악의적 인 CSRF / XSRF 자바 스크립트 가있는 악의적 인 웹 사이트를 방문 합니다.

위의 시나리오는 거의 불가능하며 비즈니스 관점에서 너무 걱정해서는 안된다는 것을 알고 있습니다. 그러나 상황을 개선하기 위해 JSON POST 데이터에 사용자 이름 / 비밀번호가 필요한 경우 도움이 될 것이라고 생각하십니까?

아니면 기본 인증을 모두 삭제하고 GET을 제거하고 승인 정보가 포함 된 POST / PUT 만 사용해야합니까? 검색된 정보를 통해 GET도 민감 할 수 있습니다.

다른 한편으로, 사용자 정의 헤더를 사용하는 것이 순수한 REST 구현으로 간주됩니까? 기본 인증을 삭제하고 맞춤 헤더를 사용할 수 있습니다. 이러한 방식으로 브라우저의 CSRF 공격을 피할 수 있으며 서비스를 사용하는 응용 프로그램은 사용자 이름 / 암호를 사용자 지정 헤더로 설정합니다. 이 접근 방식의 단점은 이제 브라우저에서 서비스를 사용할 수 없다는 것입니다.

과잉 엔지니어링? 전혀. XSRF 방지 조치는 안전한 웹 응용 프로그램 또는 서비스의 필수 부분입니다. 누군가가 귀하를 공격하기로 선택하는 것은 "매우 가능성이 낮거나 같지 않을 수도 있지만"소프트웨어의 보안 수준을 떨어 뜨리지는 않습니다.

시스템은 일반적으로 XSRF를 사용하여 공격을 받았으며 결과는 SQL 주입 또는 XSS보다 즉각적으로 나쁘지는 않지만 모든 사용자 상호 작용 기능을 손상시킬 정도로 나쁩니다.

즉, 유일한 매개 변수 만 호출 자체의 속성 인 "순수한"RESTful 인터페이스를 사용할 수 없습니다 . 침입자가 추측 할 수없는 것을 요청에 포함시켜야합니다. 즉 수있는 사용자 이름 - 암호 쌍 수 있지만 그만이 가능한 선택에서 멀리이다. 소금에 절인 암호 해시에서 생성 된 토큰과 함께 사용자 이름을 가질 수 있습니다. 인증시 서비스 자체에서 발행 한 토큰을 가질 수 있습니다 (세션에서 기억하거나 암호로 확인할 수 있음).

내가 GET을 제거해야

아니요, GET 요청은 쓰기 작업이 활성화되지 않은 읽기 요청에 사용됩니다 (“동적”). XSRF 보호가 필요한 쓰기 작업 만 가능합니다.

아무것도 믿지 마십시오. 모든 요청은 공격입니다. 모든 사용자는 해커입니다. 이 사고 방식으로 개발하면 애플리케이션이 훨씬 안전하고 안정적이며 악의적 인 사용자가 가로 챌 가능성이 줄어 듭니다. 데이터 에 심각한 문제 가 발생할 수있는 가장 귀중한 리소스 중 하나 인 보안을 둘러싼 방법을 찾는 것이 현명한 사람 입니다.

응용 프로그램에서 보안 허점을 확인한 경우 간격을 좁히기 위해 필요한 모든 것을 수행하십시오. 특히 API는 현재 가장 신뢰할 수없는 소프트웨어 여야합니다. 자격 증명이 필요하고 게시물 요청과 함께 갈 것입니다.

코드가 확립되고 유지 관리되는 경우, 에지 사례는 사례별로보고 처리해야합니다.

부품에 오류가 발생하여 수정 :

GET은 여전히 ​​적절한 RESTful 서비스의 일부로 사용되어야하며, 인증은 여전히 ​​존재해야합니다. 내가 추측하려고했던 것은 보안 목적으로 GET이 POST와 거의 동일하지만 POST는 주소 표시 줄에 정보를 넣지 않고 작업을 수행한다는 것입니다. @Lee 님이 게시

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

이것은 타사 응용 프로그램에서 사용되므로 최종 구현 자가이 부분을 혼동하지 않도록 RESTful 서비스에 대한 모범 사례를 따라야합니다.

사용자가 적극적으로 악의적이거나 "불명확 한 보안"장벽을 역 설계하는 것을 포함하여 모든 그 밖의 사건을 고려해야합니다.

그러나 동시에, 성공 핵의 영향과 시도의 가능성을 평가해야합니다. 예를 들어 :

• 견고한 방화벽으로 보호되는 내부 서비스는 공용 인터넷 서비스보다 공격을받을 가능성이 적습니다.

• 고객 토론 포럼을 중단하는 사람의 영향은 고객 신용 카드를 훔친 사람의 영향보다 적습니다.

내 요점은 "총 보안"이 "무한하게 비싸다"고 실제로 달성 할 수 없다는 것이다. 철저한 비용-편익 분석을 기반으로 선을 그릴 위치를 결정하는 것이 이상적입니다.