애플리케이션 보안 개발 고려 사항


Sina 보안 부서는 Weibo 애플리케이션이 더 나은 사용자 경험과 더 안전한 기능을 제공할 수 있도록 개방형 플랫폼에서 제품 보안을 촉진하는 데 최선을 다해 왔습니다. 현재 상황으로 볼 때 일부 애플리케이션에는 다음과 같은 일반적인 보안 취약점이나 결함이 있는 것으로 나타났습니다. 이러한 보안 취약점은 애플리케이션 자체에 영향을 미칠 뿐만 아니라 사용자에게도 손실을 초래합니다.

app secret 유출

app_secret은 애플리케이션이 access_token을 생성하도록 개방형 플랫폼에 요청하는 유일한 인증입니다. app_secret을 사용하는 목적은 개발자가 직접 애플리케이션을 사용하는지 확인하는 것입니다.


개별 애플리케이션은 개방형 플랫폼에서 리소스와 API 권한을 호출하는 인터페이스가 다릅니다. 애플리케이션의 인터페이스 리소스가 남용되고 스팸 정보 게시, 주의 추가 등 악의적인 작업이 수행되는 경우 개방형 플랫폼은 애플리케이션의 리소스 및 권한을 제한하며 이는 애플리케이션의 정상적인 API 호출에 직접적인 영향을 미칩니다. 따라서 개발자는 자신의 애플리케이션의 보안을 보호하고, 해당 보안자원이 불법적으로 사용되는 것을 방지하여 애플리케이션의 정상적인 작동을 보장해야 한다.


앱 비밀을 애플리케이션 서버에 저장하는 것이 좋습니다. 애플리케이션의 보안을 강화하려면 관리 센터/보안 설정에서 애플리케이션의 서버 IP를 바인딩하는 것이 좋습니다.


anquan1.png


애플리케이션의 앱 비밀번호가 유출된 것을 발견한 경우, 애플리케이션 관리센터에 가서 즉시 재설정하시기 바랍니다. http://open.weibo.com/apps/


앱 비밀 유출의 일반적인 이유:

1. 앱 비밀은 페이지 소스 코드 또는 URL에 나타나며, 소스 코드를 직접 보면 알 수 있습니다.

2. app_secret은 클라이언트 프로그램 자체에 저장되며, 모든 기본 애플리케이션(예: iOS, Android 또는 Windows 데스크톱 애플리케이션)은 디컴파일된 코드로 얻을 수 있습니다.

3. HTTPS 보안 전송 프로토콜은 사용되지 않으며, 공격자는 네트워크 스니핑을 통해 이를 획득합니다.

access_token 유출

access_token은 사용자가 애플리케이션을 통해 개방형 플랫폼에 액세스하는 데 사용하는 세션 ID입니다. 애플리케이션은 제3자에 의해 도난당하지 않도록 보호되어야 합니다.


access_token을 유출하는 일반적인 방법:

1. Access_token은 쿠키나 페이지 코드에 저장되며 공격자는 xss 취약점을 통해 사용자 토큰을 훔칩니다.

2. 애플리케이션 서버에 SQL 주입 취약점이 있어 사용자 토큰이 유출됩니다.


Weibo 사용자 바인딩의 CSRF 취약점

애플리케이션에 자체 계정 시스템이 있고 Weibo 사용자를 로그인하도록 바인딩하는 기능이 있는 경우 바인딩 인터페이스에 CSRF 공격을 방지하는 기능이 있는지 확인하세요. 인증 인터페이스의 상태 매개변수는 인증 프로세스 중 CSRF 공격을 방지하는 데 사용할 수 있습니다. 자세한 사용법은 SDK 코드의 최신 버전(https://github.com/ElmerZhang/WeiboSDK)을 참조하세요.

Weibo에서 CSRF 취약점을 팔로우하고 게시하세요.

CSRF 취약점에 대한 자세한 내용은 여기를 참조하세요. http://baike.baidu.com/view/1609487.htm


Weibo 애플리케이션의 CSRF 취약점은 Weibo에 팔로어 추가 및 게시와 같은 작성 인터페이스에서 흔히 발견됩니다. 사용자가 보는 것은 Weibo에 설명할 수 없는 것들이 있다는 것입니다. . 일부 마케팅 Weibo 게시물을 팔로우하거나 전달했습니다.


개발자는 리퍼러가 합법적인지 확인하거나 양식에 csrf_token을 추가하여 CSRF 공격을 예방할 수 있습니다.

사용자 신원 위조

OAuth 2.0 인증 인증이 완료되면 애플리케이션은 일반적으로 인터페이스 호출에 직접 사용되는 사용자 신원을 상징하는 access_token을 얻을 수 있습니다. 그러나 일부 애플리케이션은 애플리케이션 자체 서비스 콘텐츠를 더 많이 제공하기 위해 자체 계정 시스템과 연결된 인증 자격 증명으로 사용자의 uid를 얻어야 합니다. 일반적인 상황에는 Weibo SSO SDK를 사용하는 모바일 애플리케이션 및 네트워크 스토리지 서비스 애플리케이션이 포함됩니다.


이 시나리오에서 일반적인 취약점은 다음과 같습니다.

1 클라이언트는 인증 인터페이스에서 반환된 uid를 직접 사용하거나 access_token에서 uid를 추출하고 애플리케이션의 자체 서버를 인증 자격 증명으로 반환합니다. 이러한 전송 과정을 불법적으로 가로챌 수 있으며, uid를 변조하여 사용자의 신원을 위조할 수 있습니다.

2. 클라이언트는 access_token을 자체 서버로 다시 보내고 서버는 uid를 인증 자격 증명으로 추출하지만 access_token의 합법성을 확인하지 않습니다. 이때, 사용자 A를 속여 X 애플리케이션에 대한 권한을 부여하고, access_token을 획득하여 Y 애플리케이션 서버에 전달함으로써, A 사용자의 Y 애플리케이션에 대한 자격 증명을 획득하고 Y 애플리케이션에 있는 사용자의 서비스 콘텐츠에 접근할 수 있습니다.


복구 제안:

1. 자신의 서비스 인증 정보를 대신하여 인증 정보 없이 uid를 직접 사용하지 마세요.

2. 서버 측에서 access_token의 uid를 추출하려면 개방형 플랫폼의 OAuth2/get_token_info 인터페이스를 호출해야 합니다. 이 인터페이스를 사용할 때 access_token이 속한 앱키가 자신의 클라이언트 애플리케이션 앱키인지 여부도 확인해야 합니다. 일관된 Appkey 소스를 가진 사람만이 자체 서비스에 대한 인증 자격 증명을 교환할 수 있습니다.

3. 저장된 모든 바인딩된 access_tokens를 확인하고 access_token의 Sina uid가 바인딩된 Sina uid, 비자유 클라이언트 애플리케이션 앱 키에 의해 승인된 access_tokens, 만료된 access_tokens 및 기타 비정상적인 상황과 일치하지 않는지 확인하세요. 이런 비정상적인 사용자들.

클릭 하이재킹 취약점

악성 사이트는 Weibo 애플리케이션 사이트를 iframe에 삽입하고 HTML 투명 오버레이와 같은 기술을 사용하여 사용자의 클릭 작업을 하이재킹합니다. 사용자의 악의적인 행위를 유도하고 주의를 환기시키는 목적을 달성하기 위해.


복구 제안:


1. iframe이 필요하지 않은 애플리케이션의 경우 다음 방법 중 하나를 선택할 수 있습니다.

    • a. 헤더 선언 header("X-FRAME-OPTIONS:DENY");
    • b. JS는 현재 페이지가 iframe인지 여부를 결정합니다. 샘플 코드: if(top.location!=location){top.location =locaiton;}


2.아이프레임이 필요한 제품.

    • a. 상위 창이 허용된 페이지인지 확인합니다.
    • b. 팔로우 확인 팝업을 표시하고 팔로우 중인 사람의 닉네임을 지정합니다.


애플리케이션 보안은 위의 일반적인 보안 문제를 피하는 데 주의를 기울이는 것 외에도 최신 보안 동향에 주의를 기울이고 자체 제품의 보안 결함을 이해해야 하며 더 중요한 것은 제품과 개발자를 개선해야 안전 문제를 최대한 줄일 수 있습니다. 보안상 취약점이 발생하는 경우, 제때에 연락주시면 최대한 빨리 해결책을 제공해 드리겠습니다.