Skip to main content

Use of insecure channel - Source code

Need

Secure transmission of customer information

Context

  • Usage of Swift 5.0 for iOS app development
  • Usage of Foundation for building responsive and accessible web interfaces

Description

Non compliant code

import Foundation

let url = URL(string: "http://example.com/api/customerData")
var request = URLRequest(url: url!)

request.httpMethod = "POST"
let postString = "id=13&name=John"
request.httpBody = postString.data(using: .utf8)

let task = URLSession.shared.dataTask(with: request) { data, response, error in
guard let data = data, error == nil else {
print("error=\\(String(describing: error))")
return
}

if let httpStatus = response as? HTTPURLResponse, httpStatus.statusCode != 200 {
print("statusCode should be 200, but is \\(httpStatus.statusCode)")
print("response = \\(String(describing: response))")
}

let responseString = String(data: data, encoding: .utf8)
print("responseString = \\(String(describing: responseString))")
}
task.resume()

The above Swift code is used to send a POST request to an HTTP server. The request includes customer data such as an ID and a name. The vulnerability here is that the data is sent over an insecure channel (HTTP instead of HTTPS), which means the data is not encrypted and can be intercepted by malicious third parties.

The URL for the request is defined as http://example.com/api/customerData, which is an HTTP URL, not an HTTPS URL. This means that the connection to the server will not be encrypted.

The data that is sent in the POST request is defined in the postString variable. This data is not encrypted before being sent.

The request is then sent with URLSession.shared.dataTask(with: request). The data task sends the HTTP request and then calls a handler with the response from the server. This response is also not encrypted.

In summary, the vulnerability in this code is that it sends and receives sensitive customer data over an insecure, unencrypted channel. This could allow an attacker to intercept and read the data, leading to a potential data breach.

Steps

  • Step 1: Use HTTPS instead of HTTP for transmitting customer information.
  • Step 2: Implement SSL/TLS encryption to secure the channel.
  • Step 3: Update the URL to use the secure HTTPS protocol.
  • Step 4: Configure the server to support HTTPS and obtain a valid SSL/TLS certificate.
  • Step 5: Modify the code to use the updated secure URL for the API endpoint.

Compliant code

import Foundation

// Step 1: Use HTTPS instead of HTTP for transmitting customer information.
let url = URL(string: "https://example.com/api/customerData")
var request = URLRequest(url: url!)

request.httpMethod = "POST"
let postString = "id=13&name=John"
request.httpBody = postString.data(using: .utf8)

// Step 2: Implement SSL/TLS encryption to secure the channel.
let session = URLSession(configuration: .default, delegate: nil, delegateQueue: .main)

let task = session.dataTask(with: request) { data, response, error in
guard let data = data, error == nil else {
print("error=\\(String(describing: error))")
return
}

if let httpStatus = response as? HTTPURLResponse, httpStatus.statusCode != 200 {
print("statusCode should be 200, but is \\(httpStatus.statusCode)")
print("response = \\(String(describing: response))")
}

let responseString = String(data: data, encoding: .utf8)
print("responseString = \\(String(describing: responseString))")
}
task.resume()

The updated code now uses HTTPS instead of HTTP for transmitting customer information, which is a more secure protocol. HTTPS encrypts the data sent between the client and the server, protecting it from being read or modified by anyone else.

The URL for the API endpoint has been updated to use the secure HTTPS protocol (https://example.com/api/customerData). This ensures that the data is transmitted over a secure channel.

The URLSession configuration has been set to .default, and no custom delegate has been provided. This means that the session will use the system’s best guess for the appropriate proxy settings and credentials. If you need more control over the SSL/TLS negotiation process, you can provide a custom delegate.

The server should be configured to support HTTPS and have a valid SSL/TLS certificate. This is not shown in the code, as it is a server-side configuration.

The data task is created with the secure request, and the task is resumed. If the request completes successfully, the HTTP status code is checked to ensure it is 200, indicating success. The response data is then converted to a string and printed. If there is an error with the request, the error is printed.

References