Burp Suite 또는 유사한 도구에서 양식 제출이 가로 챌 때 게시 된 양식 데이터를 숨기는 방법이 있습니까?

HTTPS는 전송중인 데이터를 보호하는 데 사용되지만 사용자가 컴퓨터의 데이터를 조작하는 것을 방지 할 수있는 실용적인 방법은 없습니다. 거의 모든 최신 브라우저에는 사용자가 스크립트 실행을 일시 중지하고 클라이언트 스크립트 변수를 변경하고 HTML을 수정하는 등의 작업을 수행 할 수있는 기본 제공 또는 추가 개발자 도구가 있습니다.

One method that CAN be used for data that is round-tripped back and forth from the client to the server and doesn't change (such as a UserID) would be to encrypt the data prior to sending, and then decrypt when it returns to the server. Another mechanism would be to take all of your round-trip values that aren't expected to change and compute a hash against them which could be stored in a hidden field on the page. Then when they return, recompute the hash and make sure that everything matches up. Then "BobLimitedUser" couldn't change his username to "Administrator" by manipulating HTML without breaking the hash.

All of that being said, the underlying fact is simply that you should consider data coming from a system not under your control as untrusted. Final input validation should always be performed server-side (in addition to any client-side validation performed). Because of this "double validation" requirement, for complex validation routines, I'll actually use a webservice/AJAX call to perform the client-side validation. Then my client script and my server code can simply call the same routine, once during and once after submission.

If you take the approach that you will validate all input at both ends (so to speak), then tampering really shouldn't be an issue. If BobLimitedUser wants to manipulate HTML so he can change a dropdown value from one value to another value he has access to, that is his time to waste. If he manages to change something to a value that causes data integrity or security issues, that is what the server-side validation is there to protect against.

In Short

• Never trust anything generated by client script. It is simply too easy to manipulate (or even have some old script get cached by the browser, become outdated, and break something)
• Client side validation is for responsiveness and usability. Server side validation is for data integrity and security
• Don't pass sensitive information to the client and trust it to come back intact. If you must, then use encryption to protect it, or hashing to validate it.
• Don't even bother trying to encrypt/hash stuff client-side
• Do use HTTPS to protect data during transport
• Implement logging/alerting of security related errors. That way, if you get alerts every day that BobLimitedUser is attempting to exploit your app, you can talk to your IT security department and either get the virus removed from his machine, or he can be dealt with appropriately

Data validation is a big topic of discussion, and I would recommend reviewing the OWASP reference guide (simply too much information to replicate here): https://www.owasp.org/index.php/Data_Validation

마지막으로 생각해 볼 사항 ... 클라이언트 스크립트 애플리케이션이 있다면 AJAX와 웹 서비스를 사용하여 데이터를 전송하고 있다고 가정합니다. 어떤 클라이언트 스크립트를 작성하든, 악의적 인 사용자가 단순히 Fiddler와 같은 것을 사용하여 클라이언트 스크립트뿐만 아니라 브라우저 자체를 우회하여 웹 서비스에 직접 요청을 보내는 것을 방지하는 것은 무엇입니까? 보안을 보장하는 유일한 방법은 서버에서 모든 것을 검증하는 것입니다.