Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 18 replies
  • Subscribers 35 subscribers
  • Views 11961 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

KBA 135412 - Fixing SQL injection vulnerability, impact on SSL VPN

Jon Beets

The article suggests disabling HTTPS Admin Services and User Portal access on the WAN interface. While I have never had the Admin Services interface enabled, I have had the User Portal, as this was required to set up remote clients for VPN access. Is this still the case at least with a SSL VPN? If I have the User Portal disabled, will I have to manually send the EXE for the VPN client, and will I have to resend it, if any VPN settings/policies are changed?



This thread was automatically locked due to age.
Parents
  • 0

    If you disable the User Portal, you do NOT need to re-send the EXE or anything. I typically have the User Portal enabled on WAN for initial client deployment so they can download it themselves, then I cut it off on the Device Access tab.

    Any webpage with an input field like username/pass such as the User Portal or the Admin login page is exploitable using SQL injection. EDIT: exploitable *IF* input validation was not implemented, and fuzz techniques weren't implemented in Quality Assurance department

  • 0 in reply to apalm123

    Hi,

    I see you have edited your paragraph about SQL Injection. IMO it is bad programming practice and points to poor code review and code examination. It really is SQL web programming 101 to ensure SQL queries are not exploitable in this way; there are a plethora of best practice advice out there on how to prevent this happening. The fact that it was allowed in a firewall product is extremely concerning.

    Jon

Reply
  • 0 in reply to apalm123

    Hi,

    I see you have edited your paragraph about SQL Injection. IMO it is bad programming practice and points to poor code review and code examination. It really is SQL web programming 101 to ensure SQL queries are not exploitable in this way; there are a plethora of best practice advice out there on how to prevent this happening. The fact that it was allowed in a firewall product is extremely concerning.

    Jon

Children
No Data