2009-05-11 31 views
9

Tôi đang viết một dịch vụ web rất đơn giản cho ứng dụng iPhone của mình. Giả sử đây là trang http trả về một số ngẫu nhiên tại số http://mysite/getRand. Làm cách nào để đảm bảo rằng trang này chỉ có thể được truy cập từ ứng dụng iPhone của tôi chứ không phải từ các ứng dụng khách khác? Tôi đã nghĩ đến việc thực hiện một số cơ chế mật khẩu đơn giản nhưng có thể dễ dàng bị ngửi bằng cách ghi lại những gì ứng dụng của tôi gửi đi.Làm cách nào để đảm bảo quyền truy cập vào dịch vụ web của tôi chỉ từ mã của tôi?

Lý do là giảm tải của máy chủ của tôi bằng cách chỉ cho phép yêu cầu hợp pháp.

Trả lời

0

Tôi không chắc bạn đang sử dụng công nghệ web nào, nhưng nếu bạn đang sử dụng Ruby on Rails, nó sẽ sử dụng mã xác thực bí mật trong tất cả các bộ điều khiển để đảm bảo mã độc không truy cập được các phương thức phá hoại. , POST hoặc DELETE). Bạn sẽ cần phải gửi mã thông báo xác thực đó đến máy chủ trong phần yêu cầu của bạn để cho phép nó thực thi. Điều đó sẽ đạt được những gì tôi nghĩ rằng bạn đang tìm kiếm.

Nếu bạn không sử dụng Ruby on Rails, phương pháp xác thực mã có thể là một phương pháp tốt để nghiên cứu và thực hiện chính mình trong bất kỳ công nghệ nào bạn đang sử dụng.

Hãy xem Rails Security Guide, cụ thể là phần 3.1 (Các biện pháp đối phó CSRF).

0

Bạn có thể làm điều gì đó như mã hóa thời gian hiện tại và địa chỉ IP từ iPhone, sau đó giải mã nó trên máy chủ. Nhược điểm ở đây là bạn cần ứng dụng iPhone để biết khóa "bí mật" để chỉ có thể tạo mã thông báo truy cập hợp lệ ... và khi khóa nằm trong tự nhiên, nó sẽ chỉ là vấn đề thời gian trước khi nó bị tấn công nếu ứng dụng thực sự đáng để nỗ lực.

Bạn có thể mã hóa phản hồi bằng cách sử dụng một phần ngẫu nhiên của ứng dụng có nghĩa là sử dụng nó, chỉ định vị trí của nhị phân trong bit không được mã hóa của phản hồi. Sau đó, ít nhất chỉ những khách hàng có quyền truy cập vào tệp nhị phân của bạn mới có thể giải mã được ... nhưng một lần nữa, điều đó hầu như không an toàn 100%.

Cuối cùng, bạn cần phải tự hỏi mình đã nỗ lực nhiều đến mức nào để đảm bảo dịch vụ so với mức độ nỗ lực mà bạn cho rằng tin tặc sẽ lạm dụng nó.

0

Tôi không phải là nhà phát triển Cocoa Touch, nhưng tôi nghĩ rằng Xác thực HTTP qua SSL sẽ dễ triển khai và có thể đó chính xác là những gì bạn đang tìm kiếm. Tất cả những gì bạn cần làm là thiết lập xác thực HTTP ở phía máy chủ (bạn chưa đề cập đến những gì bạn đang sử dụng ở phía máy chủ) và tạo chứng chỉ SSL tự ký trên máy chủ web của bạn. Làm xong. :)

Hãy cho chúng tôi biết thêm về thiết lập của bạn và chúng tôi sẽ có thể trợ giúp thêm cho bạn.

+0

Làm cách nào để ngăn ứng dụng khác sử dụng HTTPS truy cập dịch vụ? Có, hacker sẽ cần phải tìm hiểu các chi tiết xác thực đang được sử dụng, nhưng nếu chúng ta giả định một hacker có tài nguyên, tôi không nghĩ rằng điều này sẽ ngăn chặn chúng. –

+0

Khi bạn tự hỏi: Câu hỏi đặt ra là nỗ lực mà anh ta muốn đưa vào việc bảo đảm dịch vụ. Chắc chắn, một hacker có tài nguyên có thể sử dụng tấn công MITM để tìm nạp tên người dùng/mật khẩu từ lưu lượng được mã hóa SSL, nhưng tôi nghĩ đây là một sự cân bằng giữa lợi ích và chi phí. – Javier

11

Bạn thực sự không thể thực hiện việc này. Ứng dụng của bạn có thể được tháo rời và bất cứ điều gì bí mật trong nhị phân có thể được nhân rộng trong một ứng dụng độc hại.

Một cuộc tấn công khác mà bạn cần lưu ý là mọi người cài đặt tệp máy chủ lưu trữ vào vị trí mà họ kiểm soát và sau đó cài đặt chứng chỉ gốc cho phép họ cung cấp chữ ký cho miền đó. Ứng dụng của bạn sẽ làm bài đăng với bí mật và họ chỉ có thể đọc được bí mật. Họ có thể trích xuất mật khẩu từ bất kỳ hệ thống mã hóa phức tạp nào trong hệ nhị phân theo cách này.

Hầu hết các ý tưởng trong chuỗi này đều dễ bị tấn công này.

Điều đó nói rằng, khả năng ai đó quan tâm đủ để tháo rời ứng dụng của bạn có lẽ khá xa.

Tôi chỉ đơn giản là giữ cho nó đơn giản. Có mật khẩu được mã hóa cứng vào ứng dụng của bạn. Để ngăn chặn ai đó chỉ xem xét các tài nguyên và thử mọi chuỗi, hãy biến XOR thành hai chuỗi hoặc kết quả giải mã AES của một chuỗi cố định cụ thể.

Rõ ràng, bạn nên thực hiện yêu cầu qua SSL nếu không kẻ tấn công chỉ có thể đánh lừa lưu lượng truy cập.

Có, kẻ tấn công được xác định sẽ phá vỡ lược đồ này nhưng cũng giống như bất kỳ chương trình DRM nào, điều đó luôn xảy ra. Bí quyết là làm cho nó quá nhiều nỗ lực để có giá trị nó.

+1

Đồng ý. Giống như tất cả các vấn đề bảo mật, mẹo này là làm cho lợi ích chi phí của việc truy cập dịch vụ kém. –

1

Tôi cũng sẽ sử dụng giao thức https với các khóa phía máy khách. Bạn có thể sử dụng một khóa khách hàng cho tất cả mọi người hoặc thậm chí bạn có thể tạo ra một khóa khác nhau cho mỗi khách hàng và "đăng ký" chúng tại máy chủ của bạn.

Tôi cho rằng đó là rất nhiều công việc cho dự án nhỏ, nhưng nó giống như điều thích hợp để làm nếu bạn cần xác thực.

Bạn nên kiểm tra xem chủ sở hữu điện thoại di động có dễ dàng xem khóa đó không. Và hãy nhớ rằng ai đó sẽ có thể hack nó trong mọi trường hợp.

1

Tôi giả sử bạn không muốn sử dụng SSL? Nếu bạn làm như vậy, bạn có thể mở phiên HTTPS và sau đó chuyển một số khóa bí mật trong yêu cầu.

Nếu bạn không muốn SSL lựa chọn của bạn được giới hạn: để có an ninh giả Tôi đề nghị cả hai phương pháp xác thực và ủy quyền và một phần ba để làm giảm lưu lượng tổng thể:

Xác thực: Generator trong ứng dụng client tạo ra khóa bí mật bởi kết hợp với một tập tin quan trọng. Các keyfile có thể được cập nhật thường xuyên như vậy để bảo mật hơn: cho phép nói rằng bạn cập nhật các tập tin quan trọng một lần một tuần. Để giới hạn lại: Trình kết hợp máy phát điện bí mật trong ứng dụng bằng tệp khóa ứng dụng để tạo khóa thứ 3 để truyền được sử dụng trong xác thực. Sau đó, máy chủ có thể xác thực.

Uỷ quyền: Tất nhiên bạn cũng muốn khóa các ứng dụng lừa đảo. Ở đây nó sẽ là tốt nhất để có cơ chế ủy quyền với trang web. Không thay thế keyfiles trừ khi khách hàng đăng nhập. Theo dõi các tập tin quan trọng cho người dùng. v.v.

Giảm lưu lượng truy cập: Nếu bạn đang nhận lưu lượng truy cập khiêu dâm hoặc nếu bạn nghi ngờ ai đó đang cố gắng sử dụng máy chủ của mình, bạn cũng có thể đồng bộ hóa máy chủ và máy khách để yêu cầu/phản hồi trên URL được tạo theo thủ tục thay đổi thường xuyên. Thật lãng phí khi mở/đóng rất nhiều phiên HTTPS nếu ai đó vừa mới tràn ngập bạn theo yêu cầu.

2

Để theo dõi ý tưởng của Simon, bạn có thể dễ dàng có chuỗi khóa trong ứng dụng, sau đó gửi ID thiết bị và sau đó là DeviceID XOR'ed (hoặc một số thuật toán đơn giản khác để mã hóa chuỗi) bằng chuỗi khóa của bạn .

Vì bạn biết giá trị quan trọng cần sử dụng, nên bạn không cần phải "giải mã" chuỗi này ở phía máy chủ và xác minh rằng các giá trị khớp với nhau.

Bằng cách này, mật khẩu khác nhau đối với từng thiết bị của người dùng và chuỗi "khóa" không bao giờ được gửi qua các dây của các thực thể chưa rửa lớn. :-)

Có, điều này không có nghĩa là không thể tìm ra, nhưng như những người khác đã nói, ý tưởng không phải là để làm cho nó không thể. Ý tưởng là làm cho nó rắc rối hơn nó đáng giá.

0

Như một số câu trả lời đã nêu, việc đóng dịch vụ web của bạn cho mọi người khác sẽ là một rắc rối lớn.Điều tốt nhất bạn có thể hy vọng là làm cho các tin tặc sử dụng dịch vụ web khác dễ dàng hơn để sử dụng dịch vụ web khác, hơn là sử dụng dịch vụ web của bạn ...

Một đề xuất khác là tạo số ngẫu nhiên từ random seed trên cả máy chủ và khách hàng. Máy chủ sẽ cần theo dõi vị trí của chuỗi số ngẫu nhiên tất cả các máy khách và so khớp số đó với số được khách hàng gửi.

Khách hàng cũng sẽ phải đăng ký để được cấp quyền truy cập vào máy chủ. Điều này cũng sẽ phục vụ như một cơ chế xác thực.

Vì vậy:

//Client code: 
$sequence = file_get_contents('sequence.txt'); 
$seed = file_get_contents('seed.txt'); 
$sequence++; 

//Generate the $sequence-th random number 
srand($seed); 
for ($i = 0; $i <= $sequence; $i++) { 
    $num = rand(); 
} 
//custom fetch function 
get_info($main_url . '?num=' . $num . '&id' = $my_id); 

này sẽ tạo ra một tương tự yêu cầu này:

http://webservice.com/get_info.php?num=3489347&id=3

//Server Code: (I'm used to PHP) 

//Get the ID and the random number 
$id = (int)$_REQUEST['id']; 
$rand = (int)$_REQUEST['num']; 
$stmt = $db->prepare('SELECT `sequence`, `seed` FROM `client_list` WHERE `id` = :id'); 
if ($stmt->execute(array(':id' => $id)) { 
    list($sequence, $seed) = $stmt->fetch(PDO::FETCH_ASSOC); 
} 
$sequence++; 

//Generate the $sequence-th random number 
srand($seed); 
for ($i = 0; $i <= $sequence; $i++) { 
    $num = rand(); 
} 
if ($num == $rand) { 
    //Allow Access 
} else { 
    //Deny Access 
} 

Bằng cách sử dụng aa hạt giống khác nhau cho mỗi khách hàng, bạn đảm bảo rằng các hacker không thể dự đoán một số ngẫu nhiên bằng cách theo dõi số trước được sử dụng.

1

Đây là một ý tưởng - gửi ID thiết bị cùng với các yêu cầu từ ứng dụng của bạn.

Giám sát ID của thiết bị được sử dụng - nếu bạn thấy nhiều yêu cầu từ các IP khác nhau gần hoặc cùng lúc, thiết bị đó có thể đang được sử dụng làm khóa cố định trong các yêu cầu được gửi tới bạn - chặn nó. Đối với những người thực sự gửi ID thiết bị thực từ các ứng dụng khác (không phải của bạn), bạn có thể theo dõi xu hướng sử dụng để xem các cuộc gọi có phù hợp với cách thức hoạt động của ứng dụng của bạn không - giống như một cuộc gọi được thiết bị sử dụng trước một số khởi tạo cuộc gọi bạn thường mong đợi, và như vậy - chặn những người quá. Về cơ bản bằng cách có thể thay đổi các quy tắc xung quanh các mẫu sử dụng, bạn có thể điều chỉnh tốt hơn để ai đó cố gắng sử dụng dịch vụ của bạn bằng cách đảm bảo nó không phải là mục tiêu cố định như một số khóa sử dụng ngẫu nhiên.

Bạn cũng có thể muốn sử dụng khóa sử dụng đơn giản cũng như dòng phòng thủ đầu tiên và sau đó là lớp trên phương pháp phân tích lưu lượng truy cập. Ngoài ra các giá trị tiêu đề tùy chỉnh http mà bạn tìm kiếm là một cách đơn giản khác để đi lên một kẻ tấn công ngây thơ.

Các vấn đề liên quan