我的信用卡頁面是否安全？保護查詢

Question

https：xyz dot com/authenticate/cc.php

這是我註冊的第3頁....我的會員輸入他們的信用卡。這與我的authorize.net帳戶綁定。

我最近注意到的一件事是這個頁面可以通過在URL中輸入來自行訪問..沒有必要的pre-url導致它。這似乎是不安全的，但不管是否有人想濫用它，他們可能只是通過註冊過程，並不斷提交不正確的CC號碼。花我錢對嗎？

我不記得我們是否對其設置了IP限制，或者如果這甚至是100％的保護措施。 我很確定我們做了一些事情，如果他們輸入mastercard與他們的號碼（臨時存儲），它被送回爲無效，它將匹配，並不讓他們繼續輸入錯誤的16位數字。 我應該只是讓頁面訪問沒有特定頁面允許訪問和擔心IP限制呢？難道有人不停地切換自己的IP地址，並在此頁面上提交不正確的CC或假冒的IP地址？

考慮到我/失去我的商家帳戶可能是一個有風險的人，保證這個頁面的正確方法是什麼？

預先感謝您

Answer 1

奇怪的是，你會允許直接存取權限的進程的第三步，哪裏是所有其他數據，如用戶名，ADDRES，...？

這是我會做什麼的一些想法，一個完全安全的系統（可能不存在）比我的簡單步驟複雜得多。

注，你可能想先允許用戶一些信息，您可以知道他們是誰（驗證的電子郵件地址，驗證電話號碼等），寄存器，然後只有到那時，你的信用卡的事情，如果他們時間可持續輸入錯誤或無效的號碼，你可以做別的事情，像黑列出他們，給他們打電話，侮辱他們，等等。

注2：我花了很長一段時間書面方式這一點，更多的是我閱讀並思考它，看起來越糟糕，但是因爲它已經寫好了，所以我會發布它。

的一些注意事項之前開始：

• 只有一個地址，例如/authenticate/auth.php
• 該工藝具有「狀態」，並根據這一點，它會顯示/做不同的東西。
• 對於不同的州有其他額外的文件是包括取決於國家。
• 過程開始後，會話被創建並與用戶IP，進程狀態以及任何其他關於用戶的可識別信息（例如「User-Agent」）相關聯，該數據保存在服務器中。
• 似乎你想用不同的頁面顯示不同的狀態，所以它會是這樣的。但實際上我會在使用ajax調用的單個頁面中執行操作。
• 有NO黑名單的可疑IP地址（太多正常或錯誤或完全錯誤的請求），它可以添加如果需要，但複雜性增加。你可能會也可能不想這樣做，也許capcha就足夠了，但是..
• 有NO capcha這可能有助於在某些情況下，但我在這裏描述的會話處理可能需要改變。
• 有否您可能想要做的電子郵件驗證。

假設的過程狀態是ask_name，ask_address，ask_cc等..

所以，當有在auth頁面（/authenticate/auth.php）的任何請求，這是什麼我們可以這樣做：

1如果「Referer的」不從可能的起動過程中的一個（主網頁等）或本頁面（/authenticate/auth.php）來了，我們重定向到主頁面。 結束。

這第一步避免了人們直接寫入地址或來自不受信任的頁面。

2如果有此請求沒有會話信息：

2.1如果有一個 'USER_NAME' 參數 'Referer的' 是這個頁面（/authenticate/auth.php）

2.1 .1如果該用戶名已註冊，則顯示（包括，不重定向）「ask_name.php」，並註明「用戶已註冊」。 結束。

2.1.2爲該用戶創建一個會話，將其與其IP，用戶代理等其他數據鏈接。

2.1.3設置狀態爲ask_address（第二個）並顯示'ask_address.php'。 結束。

2.2品（沒有參數或 'Referer的' 是錯誤的）

2.2.1秀 'ask_name.php'。 結束。

第二步顯示第一個屏幕（ask_user）或第二個屏幕（ask_name），它會延遲會話的創建，直到我們確信用戶想要做一些真正的事情。

它有幾個問題：

• 一些用戶（或程序）時間可持續發送請求沒有會話，但用「USER_NAME」，所以迫使你要經常檢查，如果用戶是有效還是無效，並可能慢下來。這可以使用幾種不同的技術來避免，例如使用capcha或黑名單列出一些IP一段時間。
• 一個用戶可能有可能使用'user_name'啓動該進程，但該用戶名不存在，但速度很慢並且需要一些時間才能完成該進程，而這種情況正在發生，第二位用戶開始並結束進程使用相同的'user_name'，所以當第一個用戶完成時，它會在最後一步失敗。這可以通過幾種不同的技術來避免，這些技術是作爲練習而留下的。

3如果有此請求會話信息（這是其他上一步）

3.1如果引用者是不會在本頁面或IP存儲在服務器不在與當前請求相同或者某些其他數據（如用戶代理）不同或狀態無效（不在狀態列表中），請從請求中刪除會話ID（以便瀏覽器將其刪除）並顯示'ask_name.php'額外的通知「看起來像你的設備改變了！」。 結束。

3.2「包括」爲狀態頁：

3.2.1如果參數傳遞和正確，狀態設置爲了，下一個狀態並顯示在頁面吧。如果是最後一個狀態，則爲最後狀態做適當的事情。 結束。

3.2.2顯示該狀態的同一頁面，並顯示用戶重試的錯誤消息。 結束。

最後一步試圖確保請求不是來自不同的計算機和/或被盜的會話密鑰。