1 / 21

CS 371 Web Application Programming

CS 371 Web Application Programming. Security Avoiding and Preventing Attacks. Overview. Hey, what could go wrong?. server. client. Internet. executing malicious code leaking information access to server resources. packet sniffing spoofing DOS attacks. modifying client code

ora-hudson
Download Presentation

CS 371 Web Application Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CS 371 Web Application Programming Security Avoiding and Preventing Attacks CS 371 Web Application Programming

  2. Overview Hey, what could go wrong? server client Internet • executing malicious code • leaking information • access to server resources • packet sniffing • spoofing • DOS attacks • modifying client code • session hijacking CS 371 Web Application Programming

  3. Points of Risk • data on server • what data? • how is it at risk? • cookies • sensitive data can be viewed or stolen • transmission • sniffing • losing packets CS 371 Web Application Programming

  4. CGI Scripts • using both GET and POST allow intruders to view data • scripts running on server may have limited permissions but still enough to • send out password file • view the network information maps • create a login session CS 371 Web Application Programming

  5. CGI Scripts (cont.) • hidden variables • like text vars but not displayed on browser • tempting to use to maintain state • if used for things like price, can be altered • session variables • convenient but sessions can be hijacked • provide for session time out to minimize risk • if possible encrypt session ID CS 371 Web Application Programming

  6. Logins • keep track of session • legitimate user logs in, purchases, logs out • co-worker uses back button to purchase page and buys something else • is it possible to replay the login? • erase id and password fields • create a random key for each login and use once CS 371 Web Application Programming

  7. Security Attacks • injection • sql • command • code • tampering • parameters • cookies • XSS - cross site scripting • information gathering • password cracking • denial of service CS 371 Web Application Programming

  8. SQL Injection • php script has the following query:"SELECT * FROM user WHERE name=' " + $_POST['userName'] +" '; " • what if user enters D'wan? • …name = 'D'wan'; • query will cause an error • what if user enters me';show tables; ? • what if user enters me';drop table user; ? • practice site:http://jmchilton.net/blog/?p=23 CS 371 Web Application Programming

  9. Command Injection • assume server has recipe files (ravioli.txt) • server script dumps requested recipes by shelling out the cat command:exec("cat ".$_POST['recipeName']."txt"); • user enters tuna, it returns tuna.txt • what if user enters tuna.txt;ls;cat steak ? CS 371 Web Application Programming

  10. Code Injection • server accepts text from users and displays it on page (like a guest book or comments) • user enters 'good job <script>window.location.href="bad.place.com"<script>' • In Google, when you enter a search string does that string show up on results page?hmmm CS 371 Web Application Programming

  11. Variable Tampering • in an HTML form: • <input type="hidden" name="id" value="12"/> • passed from one script to another • users can't see but hackers can easily change • in crawling web sites, they are easy to spot • session variables are safer (as long as the session isn't hijacked) CS 371 Web Application Programming

  12. Cookie Poisoning • users can modify cookies • say a web site stores somethinglike a price or total of order • user can change the amountand pay much less • to combat this, many sites store only an encrypted session id in a cookie and everything else on the server CS 371 Web Application Programming

  13. Cross Site Scripting (XSS) • injecting a link or malicious code into a web site to collect information on user • examples: • http://www.bad.com/user.php?uname=<script>alert(document.cookie);</script> • C posts a link to site B (that has vulnerability). Then A clicks on link and it emails sensitive data back to C CS 371 Web Application Programming

  14. Information Gathering • Almost every web site has info leakage • WHOIS – internet service registration • crawling the web for email and other info CS 371 Web Application Programming

  15. Password Cracking • use of back button to reveal password • using known facts of user or common words (DOB, child name, maiden name, “123456”, city, college, “love”, “letmein”, … • brute force attacks (onemansblog.com) • 4 characters => 0.86 seconds • 6 characters => 8.51 days • 8 characters => 2.1 centuries • Do you use the same password for many websites? CS 371 Web Application Programming

  16. Denial of Service • typical DOS attacks involve inundating servers with requests, but what about using client-side code to stymie user? • how would you write • a simple javascript snippet to annoy and block a user’s attempt to send a request? • a javascript function to validate user input in a non-helpful and annoying way? CS 371 Web Application Programming

  17. What to do • scripts: • keep in one folder • use standard extensions (php, etc.) • prefer compiled over interpreted • be wary of third party scripts • make no assumptions about which client-side scripts are making calls to server-side scripts • shelling out or executing code • don’t do it or minimize it’s use • be cautious of commands to be shelled CS 371 Web Application Programming

  18. What to do (cont) • variables • consider all to be tainted • escape them – magic quotes or addslashes • use javascript to validate variables but don’t rely on that alone – hackers can circumvent • php • make sure register_globals is off • include files – use .php not .inc • avoid XSS by escaping user input • obfuscate: jerry<at>myplace<dot>com CS 371 Web Application Programming

  19. Transport Layer Security (TSL) • typical algorithms require a key that both parties know • so if Alice and Bob want to communicate, how do they agree on a key? • in public key encryption, a message encrypted with public key can only be decrypted by private key encrypt decrypt CS 371 Web Application Programming

  20. Transport Layer Security (TSL) • Simplified transmission • Alice sends Bob a message to initiate • Bob responds with public key • Alice encrypts a random number with public key that only Bob can decrypt • they agree on a key using random number • Server must have a digital certificate registered with a trusted authority CS 371 Web Application Programming

  21. Web Crawling • web pages are … just documents (or scripts that produce documents) • a php script can open any url document, so it is only a matter of knowing the url • using the DOM in php, a list of the links can quickly be identified • start with one url, follow linksto other urls using a DFS orBFS CS 371 Web Application Programming

More Related