Week 59 - File Upload -> CSRF

When testing a file upload to an S3 bucket I always recommend trying to upload .html files, since in certain cases, you can use them to steal a user’s session cookie! Assuming you can successfully upload .html files, the next thing to check for is if the S3 bucket is a CNAME to a subdomain (AKA subdomain[.]example[.]com points to s3[.]amazonaws[.]com/bucket). Now if this is the case, and the application on the main domain has its session cookie marked with the ‘domain’ attribute, then you can often steal the session cookie(s) across the full scope of the main domain through the subdomain! This is assuming the ‘path’ attribute is not set to a directory outside of our file upload path. If this doesn’t work because of the ‘HttpOnly’ attribute, you can then try to pull off Cross-Site Request Forgery: would be possible on the subdomain because you could bypass the SameSite flag since the registrable domain (AKA root domain) is the same. You can also often bypass CORS since regex is frequently used to allow subdomains the ability to execute cross-origin requests. This means that it could be possible to execute a CSRF attack with POST data. Even if there’s a CSRF token, you could grab it, parse it from the response, and initiate a new request with it. To prevent this sort of attack from occurring, it is recommended to add statements to your bucket policy that allow the s3:PutObject action only for objects that have the extension of the file type that you want (images, PDFs, etc). Have any other ideas on attacking unrestricted file upload to an S3 bucket? Let me know in the comments. I have an in-depth post coming up on the modern state of Cross-Site Request Forgery, so stay tuned!

PreviousWeek 58 - Directory Traversal NextWeek 60 - Modern CSRF Attacks

Last updated 2 years ago

When testing a file upload to an S3 bucket I always recommend trying to upload .html files, since in certain cases, you can use them to steal a user’s session cookie! Assuming you can successfully upload .html files, the next thing to check for is if the S3 bucket is a CNAME to a subdomain (AKA subdomain[.]example[.]com points to s3[.]amazonaws[.]com/bucket). Now if this is the case, and the application on the main domain has its session cookie marked with the ‘domain’ attribute, then you can often steal the session cookie(s) across the full scope of the main domain through the subdomain! This is assuming the ‘path’ attribute is not set to a directory outside of our file upload path. If this doesn’t work because of the ‘HttpOnly’ attribute, you can then try to pull off Cross-Site Request Forgery: would be possible on the subdomain because you could bypass the SameSite flag since the registrable domain (AKA root domain) is the same. You can also often bypass CORS since regex is frequently used to allow subdomains the ability to execute cross-origin requests. This means that it could be possible to execute a CSRF attack with POST data. Even if there’s a CSRF token, you could grab it, parse it from the response, and initiate a new request with it. To prevent this sort of attack from occurring, it is recommended to add statements to your bucket policy that allow the s3:PutObject action only for objects that have the extension of the file type that you want (images, PDFs, etc). Have any other ideas on attacking unrestricted file upload to an S3 bucket? Let me know in the comments. I have an in-depth post coming up on the modern state of Cross-Site Request Forgery, so stay tuned!

#CSRF