Skip to main content


IAM Policies in a nutshell

A Policy is 'Deny' by default

Types of Policies:
1. SCP- SCP or Service control polcies. AWS Organizations use this kind of policies.For example, Guardrails to disable service access on the principals in the account.

2. IAM- Permission Policies and Permission Boundaries- Granular permissions on IAM principles (users and roles) and control maximum permissions they can set.

3. AWS STS- Security Token Service- Reduce general shared permissions further

4. Resource based policies: Cross-account access and to control from the resource

5. Endpoint polices- generally attached with VPCs- Control access to the service with a VPC endpoint.

How all these policies work together- within an account:

SCP AND [IAM policies OR Resource based policies]- If both policies match- then the matched action will be allowed, otherwise denied.

How all these policies work together- across accounts:

SCP AND [IAM policies AND Resource based policies]- All the 3 must have the same actions matched- the action will be …
Recent posts

Exploiting meta-data on AWS

Metadata server: Every EC2 instance has some user scripts which can be used to pull configuration to launch that EC2 instance. Those configs are stored on a Metadata server ( 'private' to that Ec2 instance. Each time an Ec2 instance starts , AWS attached the " meta data server" to it, which can be accessed from the instance itself using The instance meta-data stores information such as :AMIid, Private IP address, Instance Type etc...and...

User-data: OS boot scripts:
AWS allows you to boot up the EC2 using a custom User-data scripts- such as web application, Apache web server, keys. credentials etc. This script, also called user data, is stored by AWS in the instance metadata and retrieved by the OS during boot.

Instance profile:
When EC2 instance wants to access other services such as S3, it uses credentials to access it. Instance profiles give Ec2 instances a way to access AWS services. AWS creates a unique set of…

AWS IAM in a nutshell

IAM users: Used for Human users, such as long term security credentials

IAM roles: Used for applications, automated services, they are short term security credentials. For example, a Lambda function wants to access EC2 instance.

IAM principal: An identity defines within an AWS account

Policies: Policies are permissions- they can be attached to Users, Groups or Roles. AWS authorizes every API call against the IAM policies that apply.

Breaking down IAM Policy (JSON files):

'Effect' clause: Describes if an action is allowed or not by setting 'Allow' or 'Deny'

'Action' clause: What all actions on a particular resource can be performed. A wild card (*) indicates all actions, which is very insecure permissions

'Resource' clause: Exact resource ARN.

Policies attached to Resources (more granular level IAM policies):

Generally IAM polcicies apply to Principal, but in some scenarios, the policies can be attached to individual resources too, such who can access th…

Pointers for Websocket Security

Websocket security:
1. In case of form based authentication, the authentication must happen before WebSocket handshake. The sessiontoken must be used when doing the first handshake.
2.  The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as any cookie field value, basic authentication, digest authentication, or certificate authentication. As long there is a possibility to authenticate the user in a secure manner and the WebSocket server verifies it, the authentication mechanism in question is suitable for use.
3. After authentication comes the authorization part. Authorization is mostly application dependent and mostly controlled at the application logic leve. Same principle of least privilege are applied in this context too. Need to check if a unprivileged user is able to access/ see data/ function of other users.  qa 4. Cross-origin headers must be checked, if they allow all the sites to communicate with server, any client can c…

AWS Lambda security risks

And here is the list of top Lambda security risks:

1. Function event data injection: Injection flaws in applications are one of the most common risks and can be triggered not only through untrusted input such as through a web API call but due to the potential attack surface of serverless architecture, can also come from cloud storage events, NoSQL databases, code changes, message queue events and IoT telemetry signals, among others.

2. Broken authentication: Applications built for serverless architectures often contain dozens -- or even hundreds -- of serverless functions, each with a specific purpose.

These functions connect together to form overall system logic, but some of these functions may expose public web APIs, others may consume events from different source types, and others may have coding issues ripe for exploit and attacks, which lead to unauthorized authentication.

3. Insecure serverless deployment configuration: The security firm found that incorrect settings and the mi…

Something about NACL and Security Groups- Cloud Security

NACL and Security Groups:

1. Security Groups are attached with every EC2 instance.
2. NACLs are situarted at boundary level- at subnet bounadries.

Firewall type:
1. NACLs are Stateless firewalls- meaing they don't keep track of packest going in and out. Everytime a packet leaves a boundary, the NACL checks if this packet is going to be allwed or not, and every time a packet comes inside the boundary, it checks again if the packet is allowed to enter or not. As an analogy, NACL can be condidered as Passwport Control, which even if remebers you by face, will check for your visa and passport before letting you in.
2. Security groups are stateful firewalls- meaning they remember what packet left and do not check when they come back. They keep track of ecah packet going out and in. As an analogy, they can be considered as a security guard siitng at the front gate, who remenbers who went out and let him in.

1. As NACL is stateles, it makes the decision to let a pa…

Effective way of preventing malicious file upload

The below are all the prescribed best practices when deciding to upload a file in a web application. The below are list of implemented approaches:

A few points:

Extension whitelistng: Obvious and the first line of defense was to white listing of extensions. A simple but easily by-passable approach. Good to have this approach.File header type checking: This helps prevents the above bypass. Even if the request is captured and tampered to include a restricted file (say exe), the application will check the file header (the magic nos) of the file and reject it. Suppose an application only accepts .pdf files and expects %pdf header, but when we try uploading an exe which has a header MZ, the file will not be uploaded. In this case even though you try replacing the MZ with %pdf, the file will get uploaded but the resultant file would be treated as a pdf and not an exe, so becomes useless.Content type: The content type decides how to treat/ render this file once uploaded. The application rest…