ICO wiki - User contributions [en]

Category:I802 Firewalls and VPN IPSec (2017)

2017-09-20T07:08:48Z

Mihara: /* Services */

=Firewalls and VPN/IPSec=

==General information==

ECTS: 4

Lecturer: Lauri Võsandi

To register to this course send your SSH public key to Lauri and state which service you want to configure.

==Scenario==

In this course we will attempt to set up a network similar to a corporate network with multiple offices, eg http://docplayer.it/docs-images/20/596222/images/25-0.png

Our virtual company's story is based on [http://futurama.wikia.com/wiki/MomCorp Mom's Friendly Robot Company].

We will use VPN software to connect subnets to each other and we will use VPN software to connect our personal computers to the intranet.

==Hardware==

School's infra provides with public subnet for 62 hosts:

* IPv4 address: 193.40.244.129-188
* Subnet: /26
* Gateway: 193.40.244.188
* DNS: 8.8.8.8

That network is physically routed to 413-6-16 port in room 413.

We have total of about 264GB of RAM and couple of terabytes of SSD storage:

* Marek's box HP Proliant G5 2x quadcore Xeon, 64G RAM, 2 NIC-s (hosts 130-139)
* Madis' box HP Proliant G5, 4x quadcore Opteron, 64GB RAM, 2 NIC-s (hosts 140-149)
* Erik's box Sun 32GB, 2x 256GB SSD (hosts 155-159)
* Lauri's box HP Proliant G5 2x quadcore Xeon, 64G RAM, 2 NIC-s, 4x 250G SSD (hosts 160-179)
* Frank's box DELL 16GB, 2x 256GB SSD, 6 NIC (hosts 180-185)
* Another Sun box with 24G of RAM, dying harddisks

NB! Replace BIOS batteries; replace thermal paste

==Grading==

If you don't know what to do pick a topic from the services list below.
Send your SSH public key to Lauri and state which service you want to take care of.

Collect 100p in total to pass the course, note that there are opportunities to collect much more points in total:

* Get the service up and running (15p)
* Configure Let's Encrypt certificates for your service if applicable (15p)
* Add your service to monitoring at mon.momcorp.eu (15p)
* Enable log forwarding to log.momcorp.eu, if applicable configure auditing for your service (15p)
* Configure your service to send e-mails (mail.momcorp.eu) if applicable (15p)
* Keep the service up and running through the semester (up to -20p)
* Keep the bad guys out from your servers (up to -30p)
* Have a disaster recovery plan (up to -20p)
* Configure layer3 firewall (15p)
* Configure application firewall(s) if applicable
* Configure your laptop to connect to intranet using OpenVPN and IPSec (15p)
* Configure your mobile device to connect to intranet using OpenVPN or IPSec (15p)
* Configure your service to use authentication from AD (20p)

We will start with services facing the public internet, see what's the worst that can happen in that case and later migrate some services to intranet only. Some services will retain connectivity to public internet due to their nature (eg OwnCloud, mailserver) and some services will be available only in the intranet (eg fileserver)

==Services==

To support our virtual company in everyday business we need to provide them with a variety of services:

* www.momcorp.eu - Install webserver/load balancer and create a homepage for the company and link to remaining sites. Olusiji
* shop.momcorp.eu - Install Magento and add some fictive products like dark matter and neutron star. Sander
* wiki.momcorp.eu - Install MediaWiki, later integrate with AD. Peep
* blog.momcorp.eu - Install WordPress, later integrate with AD. Steven
* chat.momcorp.eu - Install IRC server, provide multiple channels for developers. Install some web based software for customer helldesk. Ardi
* ns1.momcorp.eu - Primary Bind9 installation, later also add DNSSEC. Erik J
* ns2.momcorp.eu - Secondary Bind9 installation in another physical host. ???
* git.momcorp.eu - Gogs installation. ???
* mon.momcorp.eu - Nagios monitoring. Nika
* mail.momcorp.eu - Mailserver with Postfix (postfw, greylisting, dkim, spf, setup secondary mx), later with AD integration if exchange won't be used. Andris
* ca.momcorp.eu - Java servlet container, EJBCA installation for certificate management. Masaki
* nas.momcorp.eu - Samba fileserver. Hindrek
* log.momcorp.eu - Graylog or similar for central logging. Kaspar, Sten-Erik
* vpn.momcorp.eu - OpenVPN gateway. Moira
* cs.momcorp.eu - Teamspeak and/or gaming server for entertainment. Christopher

Additionally for each physical box listed under Hardware we could set up:

* Person responsible for the hypervisor on that box
* Virtual machine with router OS - Mikrotik RouterOS, Vyatta, pfsense or just vanilla Debian with shell scripts

Other topics:

* Mikus - Remote management: Puppet master, DSC, postfix with kerberos (and AD?)
* Strongswan gateway
* OpenVPN gateway, later AD integration
* Exchange
* failover/high availability (heartbeat)
* db clusters/shards/replication (mysql/mariadb)
* clustered filesystems/servers (clvm, corosync, fenced, gfs)
* web caches (varnish, squid, nginx)
* load balancing (haproxy, nginx, simple roundrobin)

==Lectures==

Following lectures are planned:

* 7. sept - Intro, virtualization, containers etc. Relevant story [https://lauri.xn--vsandi-pxa.com/lan/virtualization.html here]
* 14. sept - Network topology, bridges, tagging, trunking, subnetting, LAN, WAN
* 21. sept - iptables, ebtables, packet forwarding, DNAT, SNAT, routing tables
* 28. sept - X.509 certificates, certificate authority, TLS, symmetric, asymmetric, keyexchange, Let's Encrypt, relevant slides [https://docs.google.com/presentation/d/1kqTyhhUu5CfwODmOTIC7odhlYfeEeJALTd4RX7XhPLE/edit?usp=sharing here]

Order to be determined:

* OpenVPN
* IPSec
* TBD, there are a lot of topics to discuss

Category:I802 Firewalls and VPN IPSec (2017)

2017-09-13T07:18:28Z

Mihara: /* Services */

=Firewalls and VPN/IPSec=

==General information==

ECTS: 4

Lecturer: Lauri Võsandi

To register to this course send your SSH public key to Lauri and state which service you want to configure.

==Scenario==

In this course we will attempt to set up a network similar to a corporate network with multiple offices, eg http://docplayer.it/docs-images/20/596222/images/25-0.png

Our virtual company's story is based on [http://futurama.wikia.com/wiki/MomCorp Mom's Friendly Robot Company].

We will use VPN software to connect subnets to each other and we will use VPN software to connect our personal computers to the intranet.

==Hardware==

We have total of about 264GB of RAM and couple of terabytes of SSD storage:

* Erik's box Sun 32GB, 2x 256GB SSD
* Frank's box DELL 16GB, 2x 256GB SSD, 6 NIC
* Madis' box HP Proliant G5, 4x quadcore Opteron, 64GB RAM, 2 NIC-s
* Marek's box HP Proliant G5 2x quadcore Xeon, 64G RAM, 2 NIC-s
* Lauri's box HP Proliant G5 2x quadcore Xeon, 64G RAM, 2 NIC-s, 4x 250G SSD
* Another Sun box with 24G of RAM, dying harddisks

NB! Replace BIOS batteries; replace thermal paste

==Grading==

If you don't know what to do pick a topic from the services list below.
Send your SSH public key to Lauri and state which service you want to take care of.

Collect 100p in total to pass the course, note that there are opportunities to collect much more points in total:

* Get the service up and running (15p)
* Configure Let's Encrypt certificates for your service if applicable (15p)
* Add your service to monitoring at mon.momcorp.eu (15p)
* Enable log forwarding to log.momcorp.eu (15p)
* Configure your service to send e-mails (mail.momcorp.eu) if applicable (15p)
* Keep the service up and running through the semester (up to -20p)
* Keep the bad guys out from your servers (up to -30p)
* Have a disaster recovery plan (up to -20p)
* Configure layer3 firewall (15p)
* Configure application firewall(s) if applicable
* Configure your laptop to connect to intranet using OpenVPN and IPSec (15p)
* Configure your mobile device to connect to intranet using OpenVPN or IPSec (15p)
* Configure your service to use authentication from AD (20p)

==Services==

To support our virtual company in everyday business we need to provide them with a variety of services:

* www.momcorp.eu - Install webserver/load balancer and create a homepage for the company and link to remaining sites. Olusiji
* shop.momcorp.eu - Install Magento and add some fictive products like dark matter and neutron star. ???
* wiki.momcorp.eu - Install MediaWiki, later integrate with AD. Peep
* blog.momcorp.eu - Install WordPress, later integrate with AD. Steven
* chat.momcorp.eu - Install IRC server, provide multiple channels for developers. Install some web based software for customer helldesk. Ardi
* ns1.momcorp.eu - Primary Bind9 installation, later also add DNSSEC. Erik
* ns2.momcorp.eu - Secondary Bind9 installation in another physical host. ???
* git.momcorp.eu - Gogs installation. ???
* mon.momcorp.eu - Nagios monitoring. Nika
* mail.momcorp.eu - Mailserver with Postfix (postfw, greylisting, dkim, spf, setup secondary mx), later with AD integration if exchange won't be used. Andris
* ca.momcorp.eu - Java servlet container, EJBCA installation for certificate management. ???
* nas.momcorp.eu - Samba fileserver. Hindrek
* log.momcorp.eu - Graylog or similar for central logging. Masaki
* vpn.momcorp.eu - OpenVPN gateway. Moira

Additionally for each physical box listed under Hardware we could set up:

* Person responsible for the hypervisor on that box
* Virtual machine with router OS - Mikrotik RouterOS, Vyatta, pfsense or just vanilla Debian with shell scripts

Other topics:

* Mikus - Remote management: Puppet master, DSC, postfix with kerberos (and AD?)
* Christopher - Teamspeak or game server (quake3? openarena? doom, quake, openttd), if relevant later AD integration
* Strongswan gateway
* OpenVPN gateway, later AD integration
* Exchange
* failover/high availability (heartbeat)
* db clusters/shards/replication (mysql/mariadb)
* clustered filesystems/servers (clvm, corosync, fenced, gfs)
* web caches (varnish, squid, nginx)
* load balancing (haproxy, nginx, simple roundrobin)

==Lectures==

Following lectures are planned:

7. sept - Intro, virtualization, containers etc. Relevant story [https://lauri.xn--vsandi-pxa.com/lan/virtualization.html here]
14. sept - Network topology

Order to be determined:

* iptables, ebtables, route
* X.509 certificates, TLS, symmetric, asymmetric, keyexchange, relevant slides [https://docs.google.com/presentation/d/1kqTyhhUu5CfwODmOTIC7odhlYfeEeJALTd4RX7XhPLE/edit?usp=sharing here]

Cross-Site Scripting (XSS) attacks

2017-04-24T11:33:33Z

Mihara: /* References */

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

== Attack Vectors ==

XSS attacks can be categorised into 3 types.

=== Persistent XSS (Stored XSS) ===

The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

=== Non-Persistent XSS (Reflected XSS) ===
By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

=== DOM-Based XSS ===
DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.

== XSS vulnerability ==

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

== Prevention ==
Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.

= Other Details =
Author: Masaki Ihara 
Curriculum: Cyber Security Engineering 
Group: C11 
Date created: April 24, 2017 
Last modification: April 24, 2017 

= References =

[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf Cross Site Scripting Attacks Xss Exploits and Defense]

[https://www.acunetix.com/websitesecurity/cross-site-scripting/ acunetix: cross-site-scripting]

[https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) Cross-site Scripting (XSS) - OWASP]

Cross-Site Scripting (XSS) attacks

2017-04-24T11:31:36Z

Mihara: /* References */

OSadmin wiki article

2017-04-24T11:30:32Z

Mihara: /* Chosen topics */

=Intro=
*Choose a topic from personal experience related with the subject or from topics found on the wiki page
*[[#Chosen_topics|Write the topic here]].
*Lecturer will confirm the topic
*Write your article in wiki environment
*Inform the [[Operating_systems#Lecturer|lecturer]] when the article is finished
*Receive feedback for corrections

=Requirements for the wiki article=
Author: name, group and date when the article is written

==Introduction ==
Covers points what will be discussed in the article, what are the requirements for the article reader; what are the operating system’s requirements.

==Contents==
All commands should be easily separable from the overall text.
Users should be able to copy the commands directly (additional info like prompt and user distinction symbols should be left out from the command description area)
The text should determine what user permissions are needed to perform these tasks.
The reader of your article is your fellow students, so try to avoid irrelevant information and stay on topic (don’t explain the meaning of IP address or how to install Ubuntu, when your topic is actually about htop)
All the content should be referenced.
Do not use slang and try to be grammatically correct. 

Bear in mind that this is an open environment, so everything you write in your wiki article, will be public. 

==Referencing==
Best practises of wiki referencing should be used.
Terms are but between square brackets to reference other articles in the system.
All drawing and images have to be referenced below the picture and in the text. (for example “System architecture can be viewed on image x, y and z.”)
Author’s own ideas have to be clearly presentable. Everything used from the sources have to be referenced.

==Fellow student review==
Please find a fellow student who will review your article and give a feedback on the discussion tab of the article using [http://enos.itcollege.ee/~edmund/materials/viki-artikkel/Assessment-model-for-the-wiki-article.html the following assessment model].

==Summary==
Besides a short overview, what was discussed in this article, it should also include the author's own opinion about the topic.

==Category==
Add the following category to the end of the article (last row): 
'''<nowiki>[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]</nowiki>'''

=Chosen topics=
Please write here your topic and name, group:
* '''Fedora OS'''; Anamul Hoque Shihab; CSE-11
* '''Basic Automation with Python'''; Ardi Vaba; CSE-11
* '''SSH Encryption'''; Frank Korving; CSE-11
* '''Translation of OSadmin wiki help page to English [[https://wiki.itcollege.ee/index.php/Osadmin_spikker]]'''; Peep Kuulme; CSE-11
* [https://wiki.itcollege.ee/index.php/Cross-Site_Scripting_(XSS)_attacks '''Cross-Site Scripting''']; Masaki Ihara; CSE-11
*[https://wiki.itcollege.ee/index.php/Auditd '''Auditd - Linux system monitoring with audit daemon'''], Nika Ptskialadze, CSE-11
* '''GNU Privacy Guard (GnuPG)'''; Patricia Bruno Barbosa; CSE-11
* '''BackBox OS'''; Ats Tootsi; CSE-11
*[https://wiki.itcollege.ee/index.php/creating_malware_lab '''How to create your own malware analysis lab'''], Mikus, CSE-11
*''''Arch Linux'''';Farhan Nayeem Islam;CSE-C11
* ''''VPN basics'''', Christian Cataldo, CSE-C11; [https://wiki.itcollege.ee/index.php/VPN_(English_version)]
* ''Translation of DDoS Wiki page[[https://wiki.itcollege.ee/index.php/DDoS_Eng]]'''; Andris Männik; CSE-11
*'''Translation of Ps Wiki page[[https://wiki.itcollege.ee/index.php/Ps]]'''''; Christopher Carr; CSE-11
*'''Translation of Bash_Shell wiki page[[https://wiki.itcollege.ee/index.php/BASH_shell]]'''; Steven Rugam; CSE-11
*'''Pass: The Standard Unix Password Manager'''; Oliver Rahula; CSE-11
==Ideas==
* UNIX CLI password manager https://www.passwordstore.org and its GUI http://qtpass.org/

=References=
* [https://wiki.itcollege.ee/index.php/Osadmin_referaadi_teemad counterpart article in Estonian]
* http://manpage.io
* https://linuxjourney.com/
* [https://linux.die.net/man/ Linux man-pages]
* [https://linux.die.net Linux docs]
* http://www.tecmint.com/60-commands-of-linux-a-guide-from-newbies-to-system-administrator/
* http://www.tecmint.com/useful-linux-commands-for-system-administrators/
* http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html
* http://www.thegeekstuff.com/2010/12/50-unix-linux-sysadmin-tutorials

[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]

User:Mihara

2017-04-24T11:27:02Z

Mihara: Blanked the page

XSS Attack Vectors

2017-04-24T11:26:19Z

Mihara: Blanked the page

Cross-Site Scripting (XSS) attacks

2017-04-24T11:20:14Z

Mihara: Created page with "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web appli..."

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

== Attack Vectors ==

XSS attacks can be categorised into 3 types.

=== Persistent XSS (Stored XSS) ===

The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

=== Non-Persistent XSS (Reflected XSS) ===
By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

=== DOM-Based XSS ===
DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.

== XSS vulnerability ==

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

== Prevention ==
Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.

= Other Details =
Author: Masaki Ihara 
Curriculum: Cyber Security Engineering 
Group: C11 
Date created: April 24, 2017 
Last modification: April 24, 2017 

= References =

[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf Cross Site Scripting Attacks Xss Exploits and Defense]

[https://wiki.itcollege.ee/index.php/Auditd acunetix:cross-site-scripting]

XSS Attack Vectors

2017-04-24T11:18:35Z

Mihara: Created page with " = Cross-Site Scripting (XSS) attacks = Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attack..."

= Cross-Site Scripting (XSS) attacks =

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

== Attack Vectors ==

XSS attacks can be categorised into 3 types.

=== Persistent XSS (Stored XSS) ===

The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

=== Non-Persistent XSS (Reflected XSS) ===
By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

=== DOM-Based XSS ===
DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.

== XSS vulnerability ==

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

== Prevention ==
Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.

= Other Details =
Author: Masaki Ihara 
Curriculum: Cyber Security Engineering 
Group: C11 
Date created: April 24, 2017 
Last modification: April 24, 2017 

= References =

[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf Cross Site Scripting Attacks Xss Exploits and Defense]

[https://wiki.itcollege.ee/index.php/Auditd acunetix:cross-site-scripting]

User:Mihara

2017-04-23T21:12:25Z

Mihara: /* Other Details */

User:Mihara

2017-04-23T21:11:28Z

Mihara: /* References */

= Cross-Site Scripting (XSS) attacks =

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

== Attack Vectors ==

XSS attacks can be categorised into 3 types.

=== Persistent XSS (Stored XSS) ===

The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

=== Non-Persistent XSS (Reflected XSS) ===
By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

=== DOM-Based XSS ===
DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.

== XSS vulnerability ==

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

== Prevention ==
Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.

= Other Details =
Author: Masaki Ihara
Curriculum: Cyber Security Engineering
Group: C11
Date created: April 24, 2017
Last modification: April 24, 2017

= References =

[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf Cross Site Scripting Attacks Xss Exploits and Defense]

[https://wiki.itcollege.ee/index.php/Auditd acunetix:cross-site-scripting]

User:Mihara

2017-04-23T21:07:31Z

Mihara: /* Cross-Site Scripting (XSS) attacks */

= Cross-Site Scripting (XSS) attacks =

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

== Attack Vectors ==

XSS attacks can be categorised into 3 types.

=== Persistent XSS (Stored XSS) ===

The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

=== Non-Persistent XSS (Reflected XSS) ===
By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

=== DOM-Based XSS ===
DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.

== XSS vulnerability ==

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

== Prevention ==
Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.

= Other Details =
Author: Masaki Ihara
Curriculum: Cyber Security Engineering
Group: C11
Date created: April 24, 2017
Last modification: April 24, 2017

= References =

[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf XSS Attacks]

User:Mihara

2017-04-23T21:03:15Z

Mihara:

= Cross-Site Scripting (XSS) attacks =

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

== Attack Vectors ==

XSS attacks can be categorised into 3 types.

=== Persistent XSS (Stored XSS) ===

The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

=== Non-Persistent XSS (Reflected XSS) ===
By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

=== DOM-Based XSS ===
DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.

== XSS vulnerability ==

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

== Prevention ==
Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.

== Other Details ==
Author: Masaki Ihara
Curriculum: Cyber Security Engineering
Group: C11
Date created: April 24, 2017
Last modification: April 24, 2017

User:Mihara

2017-04-23T20:59:05Z

Mihara:

== Cross-Site Scripting (XSS) attacks ==

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

== Attack Vectors ==

XSS attacks can be categorised into 3 types.

=== Persistent XSS (Stored XSS) ===

The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

=== Non-Persistent XSS (Reflected XSS) ===
By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

=== DOM-Based XSS ===
DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.

== XSS vulnerability ==

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

== Prevention ==
Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.

User:Mihara

2017-04-23T20:56:00Z

Mihara: XSS Attack Vectors

OSadmin wiki article

2017-03-11T17:15:02Z

Mihara: /* Chosen topics */

=Intro=
*Choose a topic from personal experience related with the subject or from topics found on the wiki page
*[[#Chosen_topics|Write the topic here]].
*Lecturer will confirm the topic
*Write your article in wiki environment
*Inform the [[Operating_systems#Lecturer|lecturer]] when the article is finished
*Receive feedback for corrections

=Requirements for the wiki article=
Author: name, group and date when the article is written

==Introduction ==
Covers points what will be discussed in the article, what are the requirements for the article reader; what are the operating system’s requirements.

==Contents==
All commands should be easily separable from the overall text.
Users should be able to copy the commands directly (additional info like prompt and user distinction symbols should be left out from the command description area)
The text should determine what user permissions are needed to perform these tasks.
The reader of your article is your fellow students, so try to avoid irrelevant information and stay on topic (don’t explain the meaning of IP address or how to install Ubuntu, when your topic is actually about htop)
All the content should be referenced.
Do not use slang and try to be grammatically correct. 

Bear in mind that this is an open environment, so everything you write in your wiki article, will be public. 

==Referencing==
Best practises of wiki referencing should be used.
Terms are but between square brackets to reference other articles in the system.
All drawing and images have to be referenced below the picture and in the text. (for example “System architecture can be viewed on image x, y and z.”)
Author’s own ideas have to be clearly presentable. Everything used from the sources have to be referenced.

==Fellow student review==
Please find a fellow student who will review your article and give a feedback on the discussion tab of the article using [http://enos.itcollege.ee/~edmund/materials/viki-artikkel/Assessment-model-for-the-wiki-article.html the following assessment model].

==Summary==
Besides a short overview, what was discussed in this article, it should also include the author's own opinion about the topic.

==Category==
Add the following category to the end of the article (last row): 
'''<nowiki>[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]</nowiki>'''

=Chosen topics=
Please write here your topic and name, group:
* '''Basic Automation with Python'''; Ardi Vaba; CSE-11
* '''SSH Encryption'''; Frank Korving; CSE-11
* '''Translation of OSadmin wiki help page to English [[https://wiki.itcollege.ee/index.php/Osadmin_spikker]]'''; Peep Kuulme; CSE-11
* '''XSS Attack Vectors'''; Masaki Ihara; CSE-11
==Ideas==
* UNIX CLI password manager https://www.passwordstore.org and its GUI http://qtpass.org/

=References=
* [https://wiki.itcollege.ee/index.php/Osadmin_referaadi_teemad counterpart article in Estonian]
* http://manpage.io
* https://linuxjourney.com/
* [https://linux.die.net/man/ Linux man-pages]
* [https://linux.die.net Linux docs]
* http://www.tecmint.com/60-commands-of-linux-a-guide-from-newbies-to-system-administrator/
* http://www.tecmint.com/useful-linux-commands-for-system-administrators/
* http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html
* http://www.thegeekstuff.com/2010/12/50-unix-linux-sysadmin-tutorials

[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]