신용 카드 페이지가 안전합니까? Safeguard inquiry

Question

https : xyz dot com/authenticate/cc.php

이것은 내 회원의 신용 카드 정보를 입력하는 페이지 3입니다. 이것은 내 authorize.net 계정에 묶여 있습니다.

최근에 한 가지 주목할 점은 URL에 입력하면이 페이지에 액세스 할 수 있다는 것입니다. 필요한 사전 URL이 없습니다. 이것은 안전하지 않은 것처럼 보일지라도 누군가가 악용하고 싶어도 등록 절차를 거쳐 부정확 한 CC 번호를 계속 제출할 수 있습니다.

우리는 IP 제한을 두거나 IP 100 %를 지키고 있는지 기억하지 않습니다. 나는 우리가 (일시적으로 저장된) 번호가있는 마스터 카드를 입력하면 그 번호가 잘못 입력되어 잘못된 16 자리 숫자를 계속 입력하지 못하게하는 무언가를했다고 확신한다. 단지 IP 제한에 대한 액세스 및 걱정을 허용하는 특정 페이지가 없어도 페이지를 액세스 가능하게 유지해야합니까? 누군가가 자신의 ip를 계속 변경하고 잘못된 CC 또는 가짜 IP로이 페이지를 제출할 수 없었습니까?

본인의 계정을 잃어 버리는 것을 고려하여이 페이지를 안전하게 보호하는 적절한 방법은 위험 할 수 있습니다.

는

Answer 1

당신이 과정의 3 단계로 직접 액세스를 허용 것이 이상하다, 어디 다른 모든 데이터 사용자 이름처럼 사전에 감사합니다, 요지, ...?

이것은 내가 할 수있는 몇 가지 아이디어입니다. 존재하지 않을 수도있는 완전히 안전한 시스템은 간단한 단계보다 훨씬 복잡합니다. 당신은 아마 다음 만 먼저 사용자가 (등 이메일을 확인, 확인 된 전화 번호) 당신이 그들이을 알 수있는 몇 가지 정보를 등록 할 수 싶습니다

참고, 당신은 신용을 카드 물건을 계속 입력하면 잘못된 번호를 연속적으로 입력하면 블랙리스트, 전화, 모욕 등의 다른 작업을 할 수 있습니다.

참고 2 나는 이것을 오랫동안 쓰면서 더 많이 읽었고 그것에 대해 생각하면 악화 될 것으로 보입니다. 그러나 이미 작성되었으므로 어쨌든 게시 할 것입니다.

일부 노트 이전에 시작 :

• 는
• 과정은 "상태"이에 따라이 /authenticate/auth.php 예를 들어, 하나의 주소가,이/다른 할 표시됩니다 소지품.
• 다른 주에는 상태에 따라 이 포함되어있는 다른 추가 파일이 있습니다 ().
• 프로세스가 시작되면 세션이 생성되어 사용자 IP, 프로세스 상태 및 사용자에 대한 다른 식별 가능한 정보 (예 : 'User-Agent')와 연결됩니다.이 데이터는 서버에 저장됩니다.
• 다른 페이지를 사용하여 다른 상태를 표시하려고하는 것처럼 보일 것입니다. 하지만 실제로는 아약스 호출을 사용하여 단일 페이지에서 작업을 수행합니다.
• 의심스러운 IP 주소의 블랙리스트 (정상 또는 버그가 있거나 너무 많은 요청이 너무 많음)가있는 경우 NO이 있으며 원하는 경우 추가 할 수 있지만 복잡성은 증가합니다. 당신은 이것을 원할 수도 있고 싶지 않을 수도 있지만, 아마도 모자라면 충분할 것입니다. 그러나
• 어떤 경우에는 도움이 될 수도있는 capcha가 있습니다. 그러나 여기서 설명하는 세션 처리를 변경해야 할 수도 있습니다.
• 아마 당신이하고 싶은 이메일 확인이 아니오입니다.

의 프로세스 상태는 등 ask_name, ask_address, ask_cc, 있다고 가정 해 봅시다 ... 정식 페이지 (/authenticate/auth.php)에 대한 요청이있을 때

이

그래서,이 무슨이다 우리는 할 수있는 '리퍼러'가 가능한 프로세스 선발 한 (메인 페이지, 등) 또는 페이지 (/authenticate/auth.php)에서 제공되지 않는 경우

는

1, 우리는에 리디렉션 메인 페이지. 끝.

이 첫 번째 단계는 사람들이 직접 주소를 쓰거나 신뢰할 수없는 페이지에서 오는 것을 방지합니다.

2 요청에 대한 세션 정보가없는 경우 :

2.1 "사용자 _ '파라미터 AND'참조 자 '가 존재하는 경우이 페이지 (/authenticate/auth.php) 인

2.1 .1 해당 사용자 이름이 이미 등록 된 경우 "사용자가 이미 등록되었습니다"라는 추가 통지와 함께 'ask_name.php'를 표시 (포함, 리디렉션하지 않음)하십시오. 끝.

2.1.2이 사용자에 대한 세션을 생성하고 IP, 사용자 에이전트 등의 다른 데이터와 링크하십시오.

2.1.3 상태를 ask_address (두 번째)로 설정하고 'ask_address.php'를 표시하십시오. 끝. 그렇지

2.2 (어떤 매개 변수 또는 '리퍼러가'잘못 없음)

2.2.1 쇼 'ask_name.php'. 끝.

이 두 번째 단계는 첫 번째 화면 (ask_user) 또는 두 번째 (ask_name) 중 하나를 나타내며 사용자가 실제 작업을 수행 할 때까지 세션 만들기를 지연시킵니다.

그것은 몇 가지 문제가 있습니다

• 일부 사용자 (또는 프로그램) continuosly 때문에 사용자가 유효한지 아닌지 항상 확인을 강제로 세션없이하지만 '_ 이름'로 요청을 보냅니다, 월 천천히. 이것은 여러 가지 기법을 사용하여 피할 수 있습니다 (예 : capcha 사용 또는 검은 색 IP 목록 사용).
• 한 사용자가 존재하지 않는 'user_name'을 사용하여 프로세스를 시작할 수 있지만 프로세스가 느려지고 프로세스를 완료하는 데 약간의 시간이 걸릴 수 있습니다.이 경우 두 번째 사용자가 프로세스를 시작하고 완료합니다 동일한 'user_name'을 사용하여 첫 번째 사용자가 마칠 때 마지막 단계에서 실패합니다. 이것은 운동으로 남겨진 여러 가지 기술로 피할 수 있습니다.

3이 요청에 대한 세션 정보 리퍼러가 서버에 저장이 페이지 또는 IP가 아닌 경우

3.1 (이것은 다른 이전 단계에있다)이 존재하지 않는 경우 현재 요청과 같거나 사용자 에이전트와 같은 다른 데이터가 다르거 나 상태가 유효하지 않거나 (상태 목록에 없음) 요청에서 세션 ID를 제거하여 (브라우저가 삭제하도록) 'ask_name.php'를 여분의 통지 "당신의 장치가 바뀌 었습니다 !!!". 끝.

3.2 상태에 대한 페이지 '를 포함':

3.2.1 매개 변수가 전달되는 경우 및 올바른지, 에-다음 상태를 상태를 설정하고 그것을 위해 페이지를 보여줍니다. 마지막 상태 인 경우 마지막 상태에 대해 적절한 작업을 수행합니다. 끝.

3.2.2이 상태와 동일한 페이지에 사용자가 다시 시도 할 수있는 오류 메시지가 표시됩니다. 끝.

이 마지막 단계는 요청이 다른 컴퓨터 및/또는 도난당한 세션 키로 인해 발생하지 않도록합니다.