首頁

顯示具有 資安 標籤的文章。 顯示所有文章
顯示具有 資安 標籤的文章。 顯示所有文章

AWS SAA-C03 口袋筆記 - Security

 

封包從Internet一路到Instance裡面經過的Gateway, VPC, public/private subnet等等,就像是開闢一條道路讓封包進出自己的server。如果networking沒設正確,就像道路不通,封包流量自然不會流通。當這條道路打通後,接下來就是在這條路上放上層層的安全把關。

Internet -> Shield -> NACL -> WAF -> Security Group -> Instance

簡單想像客人要進入自己家中時的層層安控。

客人 -> 保全 -> 電梯磁卡 -> 監視器 -> 房門鑰匙 -> 房間

而 Firewall Manager 就像保全公司,負責管理組織底下所有AWS Account以上的安全設定。


Security Group

  • EC2的Firewall。可以控制inbound/outbound traffic規則 (像是哪些 protocol/ports/source 可以通過)
  • request/response是stateful; 如果inbound可以進來,則outbound就一定可以出去。反之,可以出去就一定能進來。
  • 預設格則都是不允許的。

AWS WAF (Web Application Firewall) 

  • 專門用來監控網路第7層(L7, 應用程式層)的http/https 的requests。
  • 可部署於 ALB, API Gateway, CloudFront, AppSync GraphQL API, Cognito User Pool。
  • 可建立 Web ACL。規則例如:IP白名單(一個規則上限1萬筆IP), Http head/body檢查, request大小或是地理位址防堵。
  • Web ACL的設定, 除了CloudFront, 對其他服務的設定都是Regional。

NACL

  • subnet曾的firewall。
  • request/response是stateless。如果inbound可以進來,outbound可以被設定為deny, 就無法出去,這個請求最終會得不到結果。
  • 預設規則都是允許的。

AWS Shield

  • 專門用來防護DDoS攻擊。
  • AWS Shield Standard 是免費的, 預設就有啟動。保護網路第3,4層的攻擊, 像是SYN/UDP 洪水攻擊, Reflection attacks.
  • AWS Shield Advanced ($3000/mo per organization), 保護更複雜類型的攻擊。保護目標如 ELB, CloudFront, Global Accelerator, Router53.

AWS Firewall Manager 

  • 管理組織下所有的Firewall規則。像是WAF rules, Shield Advanced, Network Firewall (VPC level), DNS Firewall...etc。

--

AWS Macie 用來偵測是否有敏感資料Personal Identifiable Information (PII)的服務。透過機器學習,從S3的檔案裡偵測到可能的PII。

AWS GuardDuty 用來偵測是否有資安威脅的服務。非常適合用來保護Crypto Currency Attack。透過機器學習,從各種日誌(VPC flow logs, CloudTrail logs, DNS logs, S3 logs...etc)去偵測威脅的可能。

AWS Inspector 用來掃軟體漏洞評估(根據CVE的資料庫)。主要用在EC2 instances, ECR Container Images & Lambda Functions。

--

AWS Key Manager (KMS) 專門用來管理存取加密過的金鑰。跟大部分的AWS服務都有整合,而跟IAM有完整的整合。可以透過CloudTrail來審視KMS key的使用狀況。

System Manager (SSM) Parameter Store 用來儲存組態或機密資料。常見使用情境像是Lambda可以把db url/password等組態資料存放用此。有分Standard和Advanced兩種Tiers。差別除了價錢跟可儲存數量大小外,Advanced支援參數expiration的police。

AWS Secrets Manager 專門用來管理存取有生命週期的機密。例如每3個月更換一次密碼。常見使用情境像是與Amazon RDS, KMS的整合。支援Multi-Region Secrets (同步replica到其他region)。

AWS Certificate Manager (ACM) 專門用來管理存取TLS Certificates。常見使用情境像是ELB, CloudFront, API Gateway的整合。但這無法用在於EC2上面。


Reference

  • https://www.udemy.com/course/aws-certified-solutions-architect-associate-saa-c03
  • https://www.tenlong.com.tw/products/9786263333123?list_name=lv

Tips in Set Cookie with httpOnly and Secure flag

在Cookie上面設定httpOnly和Secure Flag時的重點整理。

首先先快速介紹這兩個flag是做甚麼用的.
1. httpOnly : cookie無法被網頁的javascript讀取,只能被server端存取。
2. secure: cookie只能透過https加密傳送

簡單的說,設定這個讓cookie更安全,可以在XSS, Session hijacking之類的攻擊有多一層防護。

在Java裡,有兩個取得Cookie的地方

第一個是從request.getCookies。這裡取的Cookie是Client端當下request裡帶的所有cookies。(參考)
第二個是從request.getHeader("Cookie")。這裡取的Cookie是Server上一次設在Set-Cookie header裡的cookies。(參考)

Session Cookie是甚麼
session cookie和cookie最大的差別是session cookie是沒有expiry date的,通常是會話結束時也會一併刪除之。而有expiry date的通常我們給予他名稱persistent cookie。但不管是哪種名稱,其實至少只要知道cookie是放在client端,session是放在server端,都是拿來記錄非常小量的資料使用的。

有時候會發現在client端讀到的cookie值跟server端所看到的值不一樣,到底是怎麼一回事?
模擬一下以下情境步驟:
1. 網頁會記住一cookie其鍵為email值為test@domain.com。
2, 當傳送到server端時,從request.getCookies所拿到的email cookie值卻會是test;從header cookie拿到的值當然不意外的,是空值。
3. Server端為了安全,會將所有cookie都帶上httpOnly和secure flags
4. 網頁第二次嘗試傳送這個email cookie值依然為test@domain.com。
5. server端從request.getCookies所拿到的email cookie值還會是test;但header cookie拿到的值卻也是test。


這樣的結果跟我們一開始的預期的結果(test@domain.com)其實落差很大,主要有幾個重點需要理解。

1. Http Cookie如果version為0時,裏頭的value不能有at sign (小老鼠) (參考),這解釋為何email被截了一大半。如果set version為1時,則會有雙引號。
2. response header SET-COOKIE 改變了client端的email cookie值為test,造成第二次在header cookie拿到的結果也變成test。
3. 如果沒有server這個SET-COOKIE的步驟,則第二次在header cookie拿到的則會是完整的email值test@domain.com。
4. 設定的httpOnly會造成javascript無法讀取這個cookie。

總結以上情境,問題的癥結如下:
後端只對自己用到的session cookie (如JSSESSIONID)做httpOnly,不需含前端的cookies
前端應該對一些敏感性的cookie資料做加密或編碼,且要避免特殊符號文字

httpOnly跟secure flag設定方法有很多種
以java為例:

1. Cookie Interface
Cookie cookie = getMyCookie("myCookieName");
cookie.setHttpOnly(true);
cookie.setSecure(true);
resp.addCookie(cookie);

2. Response header
String sessionid = request.getSession().getId();
response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + "; httpOnly; secure");

3. web.xml
<session-config>
 <cookie-config>
  <http-only>true</http-only>
  <secure>true</secure>
 </cookie-config>
</session-config>

4. Tomcat context.xml
<Context useHttpOnly="true">
...
</Context>

參考:
https://www.owasp.org/index.php/HTTPOnly
https://www.owasp.org/index.php/SecureFlag
http://docs.oracle.com/javaee/1.2.1/api/javax/servlet/http/HttpServletRequest.html#getCookies%28%29
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/Cookie.html#setValue(java.lang.String)
http://stackoverflow.com/questions/33412/how-do-you-configure-httponly-cookies-in-tomcat-java-webapps
https://en.wikipedia.org/wiki/HTTP_cookie#Session_cookie