Talk:Web application firewall

This is the talk page for discussing improvements to the Web application firewall article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing: Networking / Software / Security Mid‑importance

This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles

Mid

This article has been rated as Mid-importance on the project's importance scale.

This article is supported by Networking task force (assessed as Mid-importance).

This article is supported by WikiProject Software (assessed as Low-importance).

This article is supported by Computer hardware task force (assessed as Low-importance).

This article is supported by WikiProject Computer Security (assessed as Mid-importance).

Things you can help WikiProject Computer Security with:

Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information...

Review importance and quality of existing articles
Identify categories related to Computer Security
Tag related articles
Identify articles for creation (see also: Article requests)
Identify articles for improvement
Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
Find editors who have shown interest in this subject and ask them to take a look here.

XSS protection bypass

I'm not good at editing wiki, but I want to help include that WAF's XSS protection is not sufficient. It's really easy to evade the XSS protection.[[1]][[2]] Julian88888888 (talk) 03:59, 10 September 2020 (UTC)[reply]

i have been trying to set time aside finish up a rework on the main section of this article. i think it could be nice to include that, but i dont think it should be mentioned in the description as that should be more general and easy for people to understand. additional sections going over that would be pretty awesome though. one thing to note is that we need to provide the information in the article itself. it shouldn't force the reader to have to leave the page to read what is mentioned. essentially just stating that it can be bypassed and not how its bypassed isn't very useful [imo]. I'm going to revert the change, but if you want, please suggest a change here so we can talk see where it would fit. also, please sign your comments with the 4 tildes so everyone knows who said what.StayFree76 ^talk 00:53, 10 September 2020 (UTC)[reply]

That's a good point about not forcing them to visit another page. I'm not sure how to condense the security research into a digestible format. How each WAF is bypassed via filter evasion is is nuanced. Maybe instead it could outline different kinds of WAF, and how each was bypassed via filter evasion? Maybe something like:

In 2015, eight WAFs were tested for XSS protection. All eight failed to protect against XSS attacks via filter evasion techniques. [first source?][[3]]

For example, "Onwheel JS event +Resizingthe page by specifying the height on the style attribute" was able to trigger javascript on mousewheel events via `<body style="height:1000px" onwheel="[DATA]">`

I welcome any help/revisions to try to update this because I do want to help. My biggest issue now is that in the intro description is that it says it protects against XSS, but I think it's not sufficient to say that, given how trivial it is to bypass that protection in the WAFs tested. Julian88888888 (talk) 03:59, 10 September 2020 (UTC)[reply]

Julian88888888: that addition sounds awesome. maybe you can go even further like: ... xss protection from various vendors or even list a few of the more well known names too. i think it would still be pretty sweet if there was more "somewhat technical" stuff in the "other" sections. something like "Security bypass" for header, then mention a few of the xss issues listed in the document, how they work/ how they get around the system without putting the actual code. i think there could be a copyright concern here if the article is too close to the pdf source. that being said other articles have some sections that show example code in a block, so maybe you can add one example after the explanations. as long as the article does the explaining and it has sources then that's all we can ask for. ive been actively trying to fix a lot of the security appliance wikis past few weeks because some had tons of incorrect information. tbh, i haven't really gone through the article yet, so if you see something that should be there just remove it. as for the "protection" stuff, im with you on that. i think it could be reworded to say that the intent of the system is to detect/block those things, but they are 100% effective. also, if you use ":" before each paragraph it will intent 1 lvl per so the thread can be followed easier. (sometimes they get crazy and people respond to different people and it gets easy to lose track of whats going on.) StayFree76 ^talk 04:50, 10 September 2020 (UTC)[reply]

WAF not recommeneded

A recent update of "They also introduce a performance degradation and are easily bypassed by attackers so their deployment is not recommended.[2]" seems to be inaccurate. As I understand it, WAFs are recommended and a standard part of cloud deployments and internet facing websites. The cited source appears to be an opinion piece with a fallacy that a WAF doesn't provide cost benefit because it doesn't solve all security within its remit (arguments presented could apply to normal firewalls or any security mitigation). — Preceding unsigned comment added by 125.168.93.24 (talk) 22:26, 24 January 2024 (UTC)[reply]