Mã hóa/obfuscate các tham số HTTP

Question

Hiện tại chúng tôi đang làm việc trên một ứng dụng Web rất đơn giản và chúng tôi muốn "obfuscate" (điều gì sẽ là đúng hạn?) Hoặc mã hóa bằng cách nào đó tham số yêu cầu, vì vậy chúng tôi có thể giảm cơ hội người dùng không sử dụng gửi dữ liệu tùy ý.

Ví dụ, url trông giống như /webapp?user=Oscar&count=3

Chúng tôi muốn có somthing như: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT và có giá trị giải mã trong máy chủ với các thông tin yêu cầu thực.

Trước khi đi vào thực hiện một cái gì đó như thế này mình (và có thể làm sai) Tôi muốn biết nếu có cái gì đó để làm điều này đã?

Chúng tôi có Java trên máy chủ và JavaScript trên máy khách.

Answer 1

Không, đừng làm điều này. Nếu bạn có thể xây dựng một cái gì đó trong mã khách hàng của bạn để làm xáo trộn dữ liệu được truyền lại cho máy chủ, thì có thể một hacker cố ý. Bạn chỉ đơn giản là không thể tin tưởng dữ liệu được gửi đến máy chủ của bạn, bất kể khách hàng chính thức của bạn làm gì. Stick để thoát dữ liệu khách hàng và xác thực nó trên danh sách trắng ở phía máy chủ. Sử dụng SSL và nếu bạn có thể, hãy đặt các tham số yêu cầu của bạn trong POST thay vì GET.

Expansion chỉnh sửa

nhầm lẫn của bạn xuất phát từ mục tiêu để chặn người dùng can thiệp vào dữ liệu yêu cầu, với sự cần thiết phải thực hiện các biện pháp an ninh tiêu chuẩn. Các biện pháp bảo mật tiêu chuẩn cho các ứng dụng web liên quan đến việc sử dụng kết hợp xác thực, đặc quyền và quản lý phiên, kiểm tra đường đi, xác thực dữ liệu và các kênh truyền thông an toàn.

Sử dụng SSL không ngăn khách hàng giả mạo dữ liệu, nhưng điều này ngăn cản người đàn ông trung gian nhìn thấy hoặc giả mạo nó. Nó cũng hướng dẫn các trình duyệt được xử lý tốt để không lưu trữ dữ liệu nhạy cảm trong lịch sử URL. Có vẻ như bạn có một số loại ứng dụng web đơn giản không có xác thực và chuyển các tham số yêu cầu kiểm soát nó ngay trong GET, và do đó một số người có hiểu biết về mặt kỹ thuật có thể chỉ ra rằng user=WorkerBee có thể được thay đổi một cách đơn giản đến user=Boss trong thanh trình duyệt của họ và do đó họ có thể truy cập dữ liệu mà họ không nên xem hoặc làm những việc họ không nên làm. Mong muốn của bạn (hoặc mong muốn của khách hàng) để làm xáo trộn những tham số đó là ngây thơ, vì nó sẽ chỉ đánh dấu người hiểu biết về mặt kỹ thuật ít nhất. Đó là một biện pháp nửa nướng và lý do bạn không tìm thấy một giải pháp hiện có là nó không phải là một cách tiếp cận tốt. Bạn nên dành thời gian thực hiện một hệ thống xác thực phong nha với một đường mòn kiểm tra để đo lường tốt (và nếu điều này thực sự là những gì bạn làm, đánh dấu Gary's answer là chính xác).

Vì vậy, để quấn nó lên:

1. an ninh bởi obfuscation không an ninh tại tất cả.
2. Bạn không thể tin tưởng dữ liệu người dùng, ngay cả khi dữ liệu bị che khuất. Validate your data.
3. Sử dụng các kênh liên lạc an toàn (SSL) giúp chặn các mối đe dọa liên quan khác.
4. Bạn nên từ bỏ cách tiếp cận của bạn và làm điều đúng.Điều đúng đắn, trong trường hợp của bạn, có lẽ có nghĩa là thêm một cơ chế xác thực với một hệ thống đặc quyền để ngăn chặn người dùng truy cập vào những điều họ không phải là đặc quyền đủ để nhìn thấy - trong đó có những điều họ có thể cố gắng truy cập bởi làm xáo trộn GET tham số. Gary R's answer, cũng như nhận xét của Dave và Will nhấn cái này trên đầu.

Answer 2

Bạn có thể mã hóa dữ liệu bằng base64 hoặc tương tự. Tôi sẽ mã hóa các đối số trong JSON để tuần tự hóa chúng.

Answer 3

Nếu mục tiêu của bạn là "giảm cơ hội người dùng không sử dụng gửi dữ liệu tùy tiện", có một cách tiếp cận đơn giản hơn tôi sẽ thử. Tạo khóa mã hóa riêng và lưu trữ nó ở phía máy chủ ứng dụng của bạn. Bất cứ khi nào ứng dụng của bạn tạo ra một url, hãy tạo một băm của url bằng khóa mã hóa riêng của bạn và đặt băm đó vào chuỗi truy vấn. Bất cứ khi nào người dùng yêu cầu một trang có thông số trong url, hãy tính lại mã băm và xem nó có khớp không. Điều này sẽ cho bạn một số chắc chắn rằng ứng dụng của bạn đã tính toán url. Nó sẽ để lại các tham số chuỗi truy vấn của bạn có thể đọc được mặc dù. Trong mã giả,

SALT = "so9dnfi3i21nwpsodjf"; 

function computeUrl(url) { 
    return url + "&hash=" + md5(url + SALT); 
} 

function checkUrl(url) { 
    hash = /&hash=(.+)/.match(url); 
    oldUrl = url.strip(/&hash=.+/); 
    return md5(oldUrl + SALT) == hash; 
} 

Answer 4

Thứ gì đó giống như jCryption?

http://www.jcryption.org/examples/

Answer 5

Nếu mục tiêu đó để ngăn chặn các URL "tĩnh" không bị thao túng, sau đó bạn có thể chỉ cần mã hóa các thông số, hoặc đăng ký chúng. Nó có khả năng "an toàn đủ" để tack trên một MD5 của các tham số URL, cùng với một số muối. Muối có thể là một chuỗi ngẫu nhiên được lưu trữ trong phiên, nói.

Sau đó, bạn có thể chỉ:

http://example.com/service?x=123&y=Bob&sig=ABCD1324 

Kỹ thuật này cho thấy nhiều dữ liệu (ví dụ: họ có thể "nhìn thấy" rằng xyz = 123), nhưng họ không thể thay đổi dữ liệu.

Có một lợi thế là "mã hóa" (và tôi sử dụng thuật ngữ đó một cách lỏng lẻo). Đây là nơi bạn mã hóa toàn bộ phần tham số của URL.

đây bạn có thể làm điều gì đó như:

http://example.com/service?data=ABC1235ABC 

Những điều tốt đẹp về việc sử dụng mã hóa là hai lần.

Một chế độ bảo vệ dữ liệu (người dùng không bao giờ có thể thấy xyz = 123 chẳng hạn).

Các tính năng khác tho là nó có thể mở rộng:

http://example.com/service?data=ABC1235ABC&newparm=123&otherparm=abc 

Ở đây, bạn có thể giải mã các tải trọng ban đầu, và làm một (an toàn) kết hợp với các dữ liệu mới.

Vì vậy, các yêu cầu có thể THÊM dữ liệu cho yêu cầu, không thay đổi dữ liệu EXISTING.

Bạn có thể thực hiện tương tự thông qua kỹ thuật ký, bạn chỉ cần hợp nhất toàn bộ yêu cầu vào một "đốm" đơn lẻ và blob đó được ký hoàn toàn. Đó là "hiệu quả" được mã hóa, chỉ là một mã hóa yếu.

Rõ ràng bạn không muốn làm bất kỳ điều này trên máy khách. Không có vấn đề gì.Nếu bạn có thể làm điều đó, "họ" có thể làm điều đó và bạn không thể nói sự khác biệt, vì vậy bạn cũng có thể không làm điều đó - trừ khi bạn muốn "mã hóa" dữ liệu qua cổng HTTP bình thường (so với TLS, nhưng sau đó folks sẽ khôn ngoan tự hỏi "tại sao bận tâm").

Đối với Java, tất cả công việc này đều có trong Bộ lọc, đó là cách tôi đã làm. Sự kết thúc trở lại được phân lập từ này.

Nếu muốn, bạn có thể làm cho phần cuối được phân lập hoàn toàn khỏi bộ lọc này với bộ lọc gửi đi xử lý mã hóa/ký tên URL trên đường ra.

Đó cũng là những gì tôi đã làm.

Mặt trái là nó rất có liên quan để làm cho nó đúng và hiệu suất. Bạn cần một trình phân tích cú pháp HTML trọng lượng nhẹ để kéo ra các URL (tôi đã viết một trình phân tích cú pháp phát trực tuyến để thực hiện điều đó khi nó không sao chép toàn bộ trang vào RAM).

Mặt tươi sáng là tất cả mặt nội dung "chỉ hoạt động", vì họ không biết gì về nó.

Ngoài ra còn có một số xử lý đặc biệt khi giao dịch với Javascript (vì bộ lọc của bạn sẽ không dễ dàng "biết" nơi có URL để mã hóa). Tôi đã giải quyết vấn đề này bằng cách yêu cầu các url được ký là "var signedURL = '....'" cụ thể, vì vậy tôi có thể dễ dàng tìm thấy các url đó trong đầu ra. Không phải là nghiền một gánh nặng cho các nhà thiết kế như bạn nghĩ.

Mặt sáng khác của bộ lọc là bạn có thể tắt nó. Nếu bạn có một số "hành vi kỳ quặc" xảy ra, chỉ cần tắt nó đi. Nếu hành vi tiếp tục, bạn đã tìm thấy một lỗi liên quan đến mã hóa. Nó cũng cho phép các nhà phát triển làm việc trong văn bản thuần túy và để lại mã hóa để thử nghiệm tích hợp.

Đau phải làm, nhưng cuối cùng thì thật tuyệt.

Answer 6

Nếu bạn đang cố hạn chế quyền truy cập vào dữ liệu, hãy sử dụng một số loại cơ chế đăng nhập với cookie cung cấp khóa xác thực đăng nhập một lần. Nếu khách hàng gửi cookie bằng khóa thì họ có thể thao tác dữ liệu theo các cơ quan có liên quan đến tài khoản của họ (quản trị viên, người dùng công cộng, v.v.). Chỉ cần nhìn vào Spring Security, CAS v.v. để dễ dàng sử dụng các triển khai thực hiện điều này trong Java. Các mã thông báo được cung cấp trong cookie thường được mã hóa bằng khóa riêng của máy chủ phát hành và thường là bằng chứng giả mạo.

Hoặc, nếu bạn muốn người dùng công khai của bạn (không được xác thực) có thể đăng một số dữ liệu lên trang web của bạn, thì tất cả các phiên cược sẽ bị tắt. Bạn phải xác thực ở phía máy chủ. Điều này có nghĩa là hạn chế quyền truy cập vào một số URI nhất định và đảm bảo rằng tất cả đầu vào đều được làm sạch.

Quy tắc vàng ở đây không cho phép mọi thứ trừ những nội dung bạn biết là an toàn.