Network Security Payton Turnage, Evan French, Austin Barnett, Zane Womack, Tristan Leavitt, Andrew Hubeli

SQL Injection

SQL Injection SQL Injection attacks occur when an application takes data from an untrusted source and passes that input to a database on the backend without and kind of validation, thus allowing the user to input SQL statements that get executed. Entry Points—web form fields, cookies and parts of HTTP headers in-band SQLi Error-Based SQLi. Union-based SQL Blind SQLi—compares results of different queries that return true or false. Time-Based SQLi Out-of-Band SQLi—uses an alternative channel to extract data, such as email. Piggybacked Queries—attacker injects additional queries into the original query to alter data. White, G. (2015). CompTIA Security+. New York, NY:McGraw-Hill Education

SQL Injection Safe Practices

SQL Injection Prevention Strategies Validating Input Whitelist validation—removal of characters that are not part of an approved list. Blacklist validation—only reject input of characters or grouping of characters that are known to be malicious Stored Procedures—restricts the attacker's privileges. Surface Area Reduction—limit the number of components the DBMS is running. Safely Handle Data—encrypt sensitive information. Firewalls Web application firewall(WAF) Database Firewall Suppress Error Messages Avoid Obvious Object names Clarke,J.(2009). SQL Injection Attacks and Defense. Burlington, MA:Syngress Publishing International Journal of Computer Science, Systems Engineering and Information Technology, 2011, pp. 87-91

CSRF Attacks

Prerequisites of CSRF Attacks In order for a CSRF attack to be possible, some assumptions have to be made: the attacked website does not check the Referer HTTP header, so that it accepts requests originating from external pages. The web site accepts data modification via form submissions or URLs that have side effects which the attacker can exploit. The attacker can determine all the values for the request inputs. In the simplest case, authentication is done exclusively via a session cookie and so the attacker just have to fill non-sensitive fields. The user must load a malicious page containing the attacker's code. Judging by the amount of Facebook Likejacking, clicking on everything that moves is a pretty common behavior. https://dzone.com/articles/cross-site-request-forgery https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

CSRF Safe Practices

Origin and Referer Request Headers Require http requests to provide both an origin and referrer header. Most browsers do not allow these to be spoofed. Ensure that these have the same value and that the request does not originate from an third party referrer. Use alternative X-Forwarded-Host header and preprogram expected origin if the service operates behind a proxy.

CSRF Tokens Issue a hidden form value to users, which must be returned with their POST request. Maintain an association between user host and the particular hidden form value, which should originate from a cryptographically secure prng. A stateless solution is to persist a value of the same kind in a user’s encrypted cookie jar, requiring it be sent with each request as a header. A cross site request forger would not have access to the users’ hidden value in the cookie jar; only the correct host’s javascript could fetch it and make it a header. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet Accessed April 11

ARP Poisoning Attacks

ARP Poisoning Host on a local network requests the MAC address of where it wants to send an IP datagram to (ARP request) Request sent to the broadcast address Matching machine returns an ARP reply

ARP Poisoning ARP’s weakness is that it’s a stateless protocol Accepts all responses even if not requested A person can spoof an ARP reply and will then have packets sent to them Done through their own machine on the LAN or through a compromised machine on it Associates their own/compromised MAC address with an IP address of a target

ARP Poisoning “Stealing” packets Man-in-the-middle: Can forward the packets to the actual destination afterwards, thus avoiding detection Can forward some/all of the packets on a network to a target, causing a denial of service (DoS) attack

ARP Poisoning Safe Practices

ARP Poisoning Simplest: have read only IP-to_MAC mapping for each destination on each machine; only efficient on small networks Detection software: Crosscheck ARP responses either in individual machines or through network equipment; block non-matching ones Notification software: Notify a user upon all ARP entry changes Packet filters: Inspect packet’s source address during transmission Cryptographic network protocols: Encrypt data https://books.google.com/books?id=6weH75ATpbUC&pg=PA184#v=onepage&q&f=false https://www.veracode.com/security/arp-spoofing

DNS Spoofing Attacks

DNS Spoofing Domain Name System Spoofing: Man in the middle technique (MITM) where false DNS information is given to a host For example “google.com” is at IP address XXX.XX.XX.XX, but the host receives IP address YYY.YY.YY.YY from the attacker and is sent to fake “google.com” Mainly used with phishing to steal credentials, install malware, or cause denial of service DNS spoofing works because devices do not understand “google.com”, they understand IP addresses; therefore a request is sent to a DNS server that maps domains to IP addresses and then a response is returned

DNS Spoofing Safe Practices

DNS Spoofing Secure internal machines Helps because these attacks are usually within a network Don’t rely on DNS for secure systems Highly sensitive and secure systems should not use DNS Use intrusion detection system (IDS); they pick up most forms of DNS spoofing Use DNSSEC Alternative to DNS/future of DNS uses digitally signed records to ensure validity of response Son, Sooel; Shmatikov, Vitaly. "The Hitchhiker's Guide to DNS Cache Poisoning" (PDF). Cornell University. Retrieved April 10, 2017.