MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. Cryptanalysis research has revealed fundamental weaknesses in these algorithms and their use is not recommended in security-critical contexts.

Do not rely on MD and RIPEMD hashing algorithms for security. Effective techniques for breaking MD and RIPEMD hashes are widely available. In the case of SHA-1, current techniques still require a significant amount of computational power and are difficult to implement. However, attackers have discovered weaknesses in the algorithm and techniques for breaking it can lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. Cryptanalysis research has revealed fundamental weaknesses in these algorithms their use is not recommended in security-critical contexts.

Do not rely on MD and RIPEMD hashing algorithms for security. Effective techniques for breaking MD and RIPEMD hashes are widely available. In the case of SHA-1, current techniques still require a significant amount of computational power and are difficult to implement. However, attackers have discovered weaknesses in the algorithm and techniques for breaking it can lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Example 1: The following code utilizes a weak hashing algorithm (MD5):

NSData *imageData = [NSData dataWithContentsOfFile:file];
CC_MD5(imageData, [imageData length], result);

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, SHA-1 and Keccak are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Example 1: The following code utilizes a weak hashing algorithm (MD5):

let encodedText = text.cStringUsingEncoding(NSUTF8StringEncoding)
let textLength = CC_LONG(text.lengthOfBytesUsingEncoding(NSUTF8StringEncoding))
let digestLength = Int(CC_MD5_DIGEST_LENGTH)
let result = UnsafeMutablePointer<CUnsignedChar>.alloc(digestLength)

CC_MD5(encodedText, textLength, result)

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

The send function and its variants allow programmers to work around Ruby access specifiers on functions. In particular it enables the programmer to access private and protected fields and functions, behaviors that are normally disallowed.

Loose access configurations unnecessarily expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

DbSecurity:
  Type: 'AWS::RDS::DBSecurityGroup'
  Properties:
    GroupDescription: Ingress for Amazon RDS security group
    DBSecurityGroupIngress:
      CIDRIP: 0.0.0.0/0

By default CloudWatch Log Groups retain logs indefinitely. An unset value indicates that organizational data handling policies have not been consulted in order to set appropriate configurations. This might mean that the organization will incur unnecessary expenses in storing and managing logging events that are no longer relevant.

An attacker can launch a Denial of Wallet (DoW) attack by persistently prompting spurious event-logging over an extended period of time, which can impact the organization financially.

Example 1: The following example shows a template that fails to define a retention policy.

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  MyLogGroup:
    Type: AWS::Logs::LogGroup
  Properties:
    LogGroupName: Service01LogGroup

By default, Amazon Redshift clusters do not capture audit logs. This can allow malicious behavior to go undetected and inhibit forensic analysis in the event of a breach.

Example 1: The following example template defines an Amazon Redshift cluster without audit logging.

Resources:
  RedshiftClusterTest:
    Type: AWS::Redshift::Cluster
    Properties:
      ClusterSubnetGroupName: !Ref RedshiftClusterSubnetGroup
      ClusterType: single-node
      NumberOfNodes: !Ref RedshiftNodeCount
      DBName: !Sub ${DatabaseName}
      IamRoles:
        - !GetAtt RawDataBucketAccessRole.Arn
      MasterUserPassword: !Ref MasterUserPassword
      MasterUsername: !Ref MasterUsername
      PubliclyAccessible: true
      NodeType: dc1.large
      Port: 5439
      VpcSecurityGroupIds:
        - !Sub ${RedshiftSecurityGroup}

Systems protected by basic authentication offer attackers a potential weak link. Attackers can compromise passwords (especially weak ones) by brute-force, guessing, or social engineering.

Example 1: The following example shows a VM that allows SSH basic authentication.

{
    "resources": [
        {
            "type": "Microsoft.Compute/virtualMachines",
            "apiVersion": "2021-03-01",
            "name": "[variables('vmName')]",
            "location": "[parameters('location')]",
            ...
            "osProfile": {
                "computerName": "[variables('vmName')]",
                "adminUsername": "[parameters('adminUsername')]",
                "linuxConfiguration": {
                    "disablePasswordAuthentication": false
                }
            },
            ...
        }
    ]
}

Insufficient access configurations expose systems and broaden an organization's attack surface. Services open to interaction with the internet are subject to continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template defines an Azure Container Registry with unrestricted network access by enabling the property publicNetworkAccess and making no IP restrictions.

{
    "name": "[variables('acrName')]",
    "type": "Microsoft.ContainerRegistry/registries",
    ...
    "properties": {
        "publicNetworkAccess": "Enabled",
        ..
}

Example 2: The following example template defines an Azure Container Registry with unrestricted network access by specifying a broad allow list for the networkRuleSet property.

{
    "name": "[variables('acrName')]",
    "type": "Microsoft.ContainerRegistry/registries",
    ...
    "properties": {
        "publicNetworkAccess": "Enabled",
        "networkRuleSet":
        {
            "defaultAction": "Allow",
            "ipRules":[{
                "action": "Allow",
                "value": "*"
            }]
        }
        ...
}

Loose access configurations unnecessarily expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

GraphiQL is an in-browser tool that leverages the GraphQL schema introspection mechanism to provide a graphical interface for GraphQL API development and testing. GraphiQL helps users explore GraphQL schemas as well as compose and execute GraphQL queries.

Allowing access to GraphiQL in production is not recommended because enabling introspection of your GraphQL schemas through GraphiQL can pose a risk to your overall security posture. An attacker can use GraphiQL and introspection to obtain implementation details from a GraphQL schema that enables them to perform a more targeted attack. GraphQL schemas might leak information such as internally used fields, descriptions, and deprecation notes that are not intended for public consumption.

Example 1: The following code initializes a GraphQL endpoint with GraphiQL enabled:

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
  'graphql',
  schema = schema,
  graphiql = True
))

The Data Protection API is designed to let applications declare when items in the Keychain and files stored on the file system should be accessible. It is available for most file and database APIs, including NSFileManager, CoreData, NSData, and SQLite. By specifying one of four protection classes for a given resource, a developer can instruct the underlying file system to encrypt it either using a key derived from both the device's UID and the user's passcode or using a key solely based on the device's UID (as well as when to automatically decrypt it).

The Data Protection classes are defined in NSFileManager as constants meant to be assigned as the value for the NSFileProtectionKey key in a Dictionary associated with the NSFileManager instance, and files can be created or have their data protection class modified through use of NSFileManager functions including setAttributes(_:ofItemAtPath:), attributesOfItemAtPath(_:), and createFileAtPath(_:contents:attributes:). In addition, corresponding Data Protection constants are defined for NSData objects in the NSDataWritingOptions enum that can be passed as the options argument to NSData functions
writeToFile(_:options:). The definitions for the various Data Protection class constants for NSFileManager and NSData are as follows:

-NSFileProtectionComplete, NSDataWritingOptions.DataWritingFileProtectionComplete:
The resource is stored in an encrypted format on disk and cannot be read from, or written to, while the device is locked or booting.
Available in iOS 4.0 and later.
-NSFileProtectionCompleteUnlessOpen, NSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen:
The resource is stored in an encrypted format on disk. Resources can be created while the device is locked, but once closed, cannot be opened again until the device is unlocked. If the resource is opened when unlocked, you may continue to access the resource normally, even if the user locks the device.
Available in iOS 5.0 and later.
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication:
The resource is stored in an encrypted format on disk and cannot be accessed until after the device has booted. After the user unlocks the device for the first time, your app can access the resource and continue to access it even if the user subsequently locks the device.
Available in iOS 5.0 and later.
-NSFileProtectionNone, NSDataWritingOptions.DataWritingFileProtectionNone:
The resource has no special protections associated with it. It can be read from, or written to, at any time.
Available in iOS 4.0 and later.

So, while marking a file with NSFileProtectionCompleteUnlessOpen or NSFileProtectionCompleteUntilFirstUserAuthentication will afford it encryption using a key derived from the user's passcode and the device's UID, the data will still remain accessible under certain circumstances. As such, usages of NSFileProtectionCompleteUnlessOpen or NSFileProtectionCompleteUntilFirstUserAuthentication should be carefully reviewed to determine if further protection with NSFileProtectionComplete is warranted.

Example 1: In the following example, the given file is only protected until the user powers on the device and provides their passcode for the first time (until the next reboot):

...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
let protection = [NSFileProtectionKey: NSFileProtectionCompleteUntilFirstUserAuthentication]
do {
    try NSFileManager.defaultManager().setAttributes(protection, ofItemAtPath: filename)
} catch let error as NSError {
    NSLog("Unable to change attributes: \(error.debugDescription)")
}
...
BOOL ok = textToWrite.writeToFile(filename, atomically:true)
...

Example 2: In the following example, the given data is only protected until the user powers on the device and provides their passcode for the first time (until the next reboot):

...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
...
BOOL ok = textData.writeToFile(filepath, options: .DataWritingFileProtectionCompleteUntilFirstUserAuthentication);
...

The Data Protection API is designed to let applications declare when items in the Keychain and files stored on the file system should be accessible. It is available for most file and database APIs, including NSFileManager, CoreData, NSData, and SQLite. By specifying one of four protection classes for a given resource, a developer can instruct the underlying file system to encrypt it either using a key derived from both the device's UID and the user's passcode or using a key solely based on the device's UID (as well as when to automatically decrypt it).

The Data Protection classes are defined in NSFileManager as constants meant to be assigned as the value for the NSFileProtectionKey key in a Dictionary associated with the NSFileManager instance. Files can be created or have their data protection class modified through use of NSFileManager functions including setAttributes(_:ofItemAtPath:), attributesOfItemAtPath(_:), and createFileAtPath(_:contents:attributes:). In addition, corresponding Data Protection constants are defined for NSData objects in the NSDataWritingOptions enum that can be passed as the options argument to NSData functions such as
writeToFile(_:options:). The definitions for the various Data Protection class constants for NSFileManager and NSData are as follows:

-NSFileProtectionComplete, NSDataWritingOptions.DataWritingFileProtectionComplete:
The resource is stored in an encrypted format on disk and cannot be read from, or written to, while the device is locked or booting.
Available in iOS 4.0 and later.
-NSFileProtectionCompleteUnlessOpen, NSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen:
The resource is stored in an encrypted format on disk. Resources can be created while the device is locked, but once closed, cannot be opened again until the device is unlocked. If the resource is opened when unlocked, you may continue to access the resource normally, even if the user locks the device.
Available in iOS 5.0 and later.
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication:
The resource is stored in an encrypted format on disk and cannot be accessed until after the device has booted. After the user unlocks the device for the first time, your app can access the resource and continue to access it even if the user subsequently locks the device.
Available in iOS 5.0 and later.
-NSFileProtectionNone, NSDataWritingOptions.DataWritingFileProtectionNone:
The resource has no special protections associated with it. It can be read from, or written to, at any time.
Available in iOS 4.0 and later.

Even though all files on an iOS device, including those without an explicitly assigned Data Protection class, are stored in an encrypted form, specifying NSFileProtectionNone results in encryption using a key derived solely based on the device's UID. This leaves such files accessible any time the device is powered on, including when locked with a passcode or when booting. As such, usages of NSFileProtectionNone should be carefully reviewed to determine if further protection with a stricter Data Protection class is warranted.

Example 1: In the following example, the given file is not protected (accessible anytime the device is powered on):

...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
let protection = [NSFileProtectionKey: NSFileProtectionNone]
do {
    try NSFileManager.defaultManager().setAttributes(protection, ofItemAtPath: filename)
} catch let error as NSError {
    NSLog("Unable to change attributes: \(error.debugDescription)")
}
...
BOOL ok = textToWrite.writeToFile(filename, atomically:true)
...

Example 2: In the following example, the given data is not protected (accessible anytime the device is powered on):

...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
...
BOOL ok = textData.writeToFile(filepath, options: .DataWritingFileProtectionNone);
...